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...@mega-nerd.com <flac-dev.pyt.682528eb7b.mle+la#mega-nerd....@ob.0sg.net> wrote: > pyth.flac-dev.5....@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 >
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
