I agree with Miroslav. It is a good practice to make a security release on a "branch" of the stable, shipped code, so that people can obtain the security fix with minimal risk to other changes. Even if the new code passes all tests fairly soon, it wouldn't hurt to have a couple of releases - one purely for security, the next with new changes in other areas.
Brian Willoughby On Nov 24, 2014, at 12:47 AM, Miroslav Lichvar <mlich...@redhat.com> wrote: On Sun, Nov 23, 2014 at 02:44:00AM -0800, Erik de Castro Lopo wrote: > lvqcl wrote: > >> I have a couple of questions: >> >> 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any >> pre-releases? > > I had not planned to do a pre-release. FWIW, considering how much code has changed since 1.3.0, I'd rather see the security bug fixed in a new 1.3.0 release, maybe with some other serious bugs like the metaflac memory corruction, and have a prerelease for 1.3.1 to test it thoroughly. I know the new release is almost ready, but if some serious bug is found in 1.3.1, a new release will have to be made anyway to not force the users to the vulnerable version. -- Miroslav Lichvar _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
