[flac-dev] Tag flac as flac 1.2.1_git

[Brian Willoughby]

The amount of time that has passed since the last change has nothing  
to do with the version number.

I'm inclined to believe that 1.2.2 would be appropriate.

I'm sure there will be other, more appropriate ways to celebrate the  
new release after the long period of stability.

Brian Willoughby
Sound Consulting


On Jan 11, 2013, at 23:56, pyth.flac-dev.5.pyt at spamgourmet.com wrote:
> The initial rule was, if I can recall correctly :
>
> - Changes in the first digit (e.g. 1.x.x to 2.x.x) indicate a break  
> in backwards compatibility ; i.e. the formats are totally different.
> - Changes in the second digit indicate backward-compatible changes  
> in the format (i.e. a 1.1.x-encoded file is only a particular case  
> of a 1.2.x-encoded file)
> - Changes in the third digit reflect any other, non-format related,  
> change. In particular, any 1.2.x decoder can decode any 1.2.y- 
> encoded file.
>
> I think it best to stick to that, but you're doing the work, so you  
> pick up what you think best or easiest. I believe however it is  
> good to have rules that precisely govern what number changes.
>
> Cheers,
> Pyt.
>
>
> On Sat, Jan 12, 2013 at 8:37 AM, Erik de Castro Lopo - mle+la at mega- 
> nerd.com <flac-dev.pyt.682528eb7b.mle+la#mega-nerd.com at ob.0sg.net>  
> wrote:
>> pyth.flac-dev.5.pyt at spamgourmet.com wrote:
>>
>> > I seem to recall that changes in the second number indicated a  
>> minor change
>> > in the *format* of the file itself (for example, 1.1.x to 1.2.x  
>> introduced
>> > a new rice coding option used for 24-bit files).
>>
>> I wasn't aware of that.
>>
>> > Are there any format changes that would justify that ?
>>
>> I consider the first release in 5 years to be a sufficiently major
>> thing to warrant the bump in versions number, but if people thing
>> 1.2.2 or 1.2.10 or whatever is mor appropriate then I'll go with
>> that.
>
>