[flac-dev] Tag flac as flac 1.2.1_git

pyth.flac-dev.5.pyt at spamgourmet.com pyth.flac-dev.5.pyt at spamgourmet.com
Fri Jan 11 23:56:03 PST 2013


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.
>
> Cheers,
> Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20130112/9a6eb9f5/attachment.htm 


More information about the flac-dev mailing list