[flac-dev] Tag flac as flac 1.2.1_git

[Brian Willoughby]

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