[asterisk-dev] 1.6.0.13: sounds 1.4.14, but rc2 was 1.4.15

[sean darcy]

Tilghman Lesher wrote:
> On Wednesday 12 August 2009 04:40:02 Russell Bryant wrote:
>> sean darcy wrote:
>>> 1.6.0.13:
>>>
>>> make[1]: Entering directory `/home/asterisk/asterisk-1.6.0.13/sounds'
>>> --20:56:18--
>>> http://downloads.digium.com/pub/telephony/sounds/releases/asterisk-core-s
>>> ounds-en-wav-1.4.14.tar.gz => `asterisk-core-sounds-en-wav-1.4.14.tar.gz'
>>>
>>> but in 1.6.0.11-rc2 it used 1.4.15.
>>>
>>> Any reason for this change?
>> Yeah, it has to do with the release numbering becoming a bit confusing
>> due to an unexpected security release.
>>
>> 1.6.0.11 was in the RC state, and then we had to make a security
>> release.  We didn't want to call it 1.6.0.11, as it doesn't include all
>> of the bug fixes that were staged to be released as 1.6.0.11 as
>> indicated by the release candidates.  So, instead, we went to the next
>> version number.  There was a build error with 1.6.0.12, so it became
>> 1.6.0.13.
>>
>> Now, we'll push out a 1.6.0.14-rc1, which will be a continuation of the
>> release candidate series that was originally going to be 1.6.0.11.
>>
>> Hopefully that makes sense.
> 
> Actually, Russell, I think he's asking about the asterisk-sounds release
> moving back a version, not the Asterisk versioning.  The reason for the
> -sounds release staying at 1.4.14 is that the 1.6.0.13 release is an
> EXACT copy of 1.6.0.10, plus the security fixes.  That is, we don't change
> anything else in a security release, from the previous full release.  Given
> that 1.6.0.11-rc2 was not a full release, but merely a release candidate,
> the changes introduced in that version won't be seen in a security release
> until there's been a full release with those changes.  The version of sounds
> tarball is indicated in the sounds directory Makefile, which is not something
> that typically changes during a security release.
> 

BTW, unless I missed it, there's no announcement of 1.6.0.13.

sean