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
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 vers
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 f
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
Brian Willoughby wrote:
> The flac front-end utility should have its own version number, on a
> separate schedule from the flac library. I can see that we'd be able
> to add features to the utility quite extensively without ever
> changing the file format or the library. I realize that the u
On 13-01-17 7:26 PM, Brian Willoughby wrote:
> The flac front-end utility should have its own version number, on a
> separate schedule from the flac library. I can see that we'd be able
> to add features to the utility quite extensively without ever
> changing the file format or the library.
The flac front-end utility should have its own version number, on a
separate schedule from the flac library. I can see that we'd be able
to add features to the utility quite extensively without ever
changing the file format or the library. I realize that the utility
has historically shared
On 13-01-16 11:10 PM, Erik de Castro Lopo wrote:
> My understanding is that the recent changes for 7 and 8 channels was
> a documentation change only.
I think we should also change the flac front-end utility to construct
and interpret the WAVE channel mask for 7 and 8 channel files. No one
has wr
On 17-01-13 08:10, Erik de Castro Lopo wrote:
> There were no code changes to the FLAC library or tools.
My mistake, I assumed that because of this documentation change, the
FLAC utility would be updated as well to handle this correctly.
___
flac-dev m
Martijn van Beurden wrote:
> Well, the only change in format that might be merged before the next
> release that I know of is the definition of the mapping of 7- and
> 8-channel audio. As these were previously unmapped, this would qualify
> to be a minor format change, as previous decoders won'
I second Brian's position on the matter, for what it's worth...
Pyt.
On Sun, Jan 13, 2013 at 12:46 AM, Brian Willoughby wrote:
>
> On Jan 12, 2013, at 14:28, Martijn van Beurden wrote:
> > On 12-01-13 22:46, Brian Willoughby wrote:
> >> I would suggest that everyone keep in mind the vast inst
On Jan 12, 2013, at 14:28, Martijn van Beurden wrote:
> On 12-01-13 22:46, Brian Willoughby wrote:
>> I would suggest that everyone keep in mind the vast installed base of
>> hardware FLAC recorders and players, and not senselessly make them
>> obsolete without extremely compelling reasons.
>
> Th
On 12-01-13 22:46, Brian Willoughby wrote:
> I would suggest that everyone keep in mind the vast installed base of
> hardware FLAC recorders and players, and not senselessly make them
> obsolete without extremely compelling reasons.
This can be done for the same reason the change from 1.1 to 1.2
On Jan 12, 2013, at 05:30, Martijn van Beurden wrote:
> On 12-01-13 08:23, 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 codi
On 12-01-13 08:23, 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).
Well, the only change in for
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
S
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
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
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). Are there any format
changes that would justify that ? Otherwise, 1.2.2 would seem more
appropriate
Jaren Stangret wrote:
> Whether we name it 1.2.2pre or 1.2.2snapshot or something entirely
> different, is just fine. I guess I was making the point that if a new
> release is in the works, some sort of pre-release to test would be nice.
I'm currently looking to name it 1.3.0rc1. 1.3.0 because i
I agree on everything you said. I did not intend or expect to have
pre-release flac bundled with software, but can understand the dismay at my
earlier request.
If people think there should be a snapshot version for testing, I'm all for
it, especially now that the build system has undergone some c
Hi,
On 07.01.2013, at 01:46, Jaren Stangret wrote:
> I know Erik is busy with maintenance and wants to get a release out soon. In
> the meantime, is it appropriate to tag HEAD as 1.2.1_git and include this in
> the CLI tools (flac, metaflac, etc)?
>
> This would make it easier to allow progra
I know Erik is busy with maintenance and wants to get a release out soon.
In the meantime, is it appropriate to tag HEAD as 1.2.1_git and include
this in the CLI tools (flac, metaflac, etc)?
This would make it easier to allow programs in development to test against
git flac and older flac version
23 matches
Mail list logo
