On Jan 21, 2013, at 22:57, Erik de Castro Lopo wrote:> IMO, any code change at all, even just whitespace is worthy of its > own version number. If the md5sum of the source code tarball is > different it warrants an updated version number.Why would you release a new version of FLAC if the binary did not change (on a given platform)? I realize that whitespace is an extreme example, but in that case you don't really need a new version. The source code is only consumed by the developers. The version control system should handle "versions" of the source code. For example, Subversion would assign a new repository version number every time someone checks in a source code change. That is enough. There's no need to revise the release version with every developer's key press. It seems to me that you have to change more than source whitespace before a public release is warranted. A public release of substantial changes (not whitespace) would require at least a 0.0.1 increment in version number.>> If we can agree on separating the library and utility version >> numbers, then I think we'll have a much better chance of agreeing on >> version numbers. > > Its use in the test suite means it can't be extracted from the > FLAC library sources without replicating its capabilities which > would just be silly.It would be silly to replicate the command line utility, but you don't have to replicate it to change its version number, or to allow the version to digress from the format library version.>> Not to mention the fact that embedded devices >> without a command line or any other kind of utility won't needlessly >> see version number changes when the format remains the same. > > Not even bug fixes?What bugs? I'm not aware of any bugs. A centralized list of bugs would be great. I'm sure there is one and I just haven't looked at it in a while. Is the old bug database still active? Is there a bug search template or report showing the serious bugs that need fixing?>> On that >> note, I suppose this means we might want to mark FLAC files with the >> version of the utility that created them, since the format version >> number won't indicate that going forward - perhaps an application >> block would be appropriate. > > Sorry, but I actually think you have this completely around the wrong > way. FLAC files can be created without the flac command line utility. > That suggests that FLAC files should be marked with the *library* > version that was used to create them.The last suggestion on my part was a nod to the folks who want to define the channel mappings in a way that can be detected by players when looking at a specific media file. The FLAC format (library) does not need to be modified for this, because FLAC merely holds independent channels without any care about their order or position or labeling. But the command line utility might transcode channel mappings from other formats like WAVE or AIFF. In that case, having the command- line utility version number might help define the channel mapping. Then again, it would be better to define metadata specifically for the purpose of channel mappings rather than encoding the command-line version number into the stream. I'll just take this particular suggestion off the table, because there are better ways to provide the features desired. To clarify, I was not suggesting that the FLAC format version should be replaced by the command-line utility version - that would certainly be a bad idea, as you point out. I should have specified that I meant adding a secondary version number somewhere in the stream (meta blocks) to indicate any assumption about data that isn't part of individual channels. Brian
On 22-01-13 08:20, Brian Willoughby wrote:>> Not even bug fixes? > What bugs? I'm not aware of any bugs. A centralized list of bugs > would be great.Well, the changelog in the docs directory has been used previously by Josh to keep track of all changes. It seems the code in cvs had some bugs fixed and libFLAC got an new function (FLAC__format_blocksize_is_subset()) so that should be enough to warrant a new version number right? Anyway, the Sourceforge bugtracker is still active: http://sourceforge.net/p/flac/bugs/
Brian Willoughby wrote:> Why would you release a new version of FLAC if the binary did not > change (on a given platform)?The version number is attached to the source code not the binary. BSD distros, Linux distros and things like MacPorts have scripts that rely on the md5sum of a given version of the source code tarball to be the same from the time it was released until the end of time. Uploading a new version of the source code with a different md5sum generates manual work for dozens of people around the world and wastes 100s of hours of people's time. It also results in a bunch *users* of systems that compile from source (like *BSD, Gentoo Linux and probably also MacPorts etc) to having install/compile time errors that they don't understand.> The source code is only consumed by the developers.Not true. Anybody who uses FLAC on things like any of the *BSDs or Gentoo linux compiles FLAC from source and expects the md5sum of a given version to be constant. In fact some of these people are not actually developers, but more like sysadmins.> The version > control system should handle "versions" of the source code. For > example, Subversion would assign a new repository version number > every time someone checks in a source code change. That is enough. > There's no need to revise the release version with every developer's > key press.We're talking about different things here. You are talking about revision control versions and I'm talking about official release source code tarballs.> A public release of substantial changes (not whitespace)I would never do a public release that only contained whitespace changes. It causes needless work for package maintainers across the Unix, Linux and Mac ecosystems (probably Windows too).> would require at least a 0.0.1 increment in version number.Agreed.> It would be silly to replicate the command line utility, but you > don't have to replicate it to change its version number, or to allow > the version to digress from the format library version.Having three different version numbers, ie: - Source code version number - libFLAC version number - flac utility version number also creates all sorts of headaches for people doing binary packaging of FLAC for things like Linux, *BSD and Mac. I see this from both sides. I am both an upstream author/maintainer and a packager for Debian. Keeping the version numbers the same across the board makes life easier for a bunch of people who are over worked volunteers with insufficient time.> > > Not to mention the fact that embedded devices > > > without a command line or any other kind of utility won't needlessly > > > see version number changes when the format remains the same. > > > > Not even bug fixes? > > What bugs?Hypothetical bugs. You made a blanket statement that the command line version number should remain the same when the format remain the same. I was refuting that.> > Sorry, but I actually think you have this completely around the wrong > > way. FLAC files can be created without the flac command line utility. > > That suggests that FLAC files should be marked with the *library* > > version that was used to create them. > > The last suggestion on my part was a nod to the folks who want to > define the channel mappings in a way that can be detected by players > when looking at a specific media file.That should depend on the presence or absence of an optional metadata chunk and should not depend on the version number. For instance if we add the channel mapping metadata chunk, it should still be optional after we add it.> The FLAC format (library) does > not need to be modified for this, because FLAC merely holds > independent channels without any care about their order or position > or labeling.Sorry, the software engineer in me says the *only* place to implement this is in the library. Doing it in the library means that using the library is the lowest barrier to use so we don't end up with more than one (possible buggy and/or incompatible) implementations.> But the command line utility might transcode channel mappings from > other formats like WAVE or AIFF.Sure, but when reading or writing the channel mapping from FLAC it should do so using the libFLAC functions provided for that purpose. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
Martijn van Beurden wrote:> Well, the changelog in the docs directory has been used previously by > Josh to keep track of all changes. It seems the code in cvs had some > bugs fixed and libFLAC got an new function > (FLAC__format_blocksize_is_subset()) so that should be enough to warrant > a new version number right?More than enough. The new version will be 1.3.0 (with some pre-release versions first). Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/