On Fri, Jun 3, 2011 at 5:05 PM, Reinhard Tartler <[email protected]>wrote:
> On Fri, Jun 03, 2011 at 21:49:52 (CEST), Måns Rullgård wrote: > > > Reinhard Tartler <[email protected]> writes: > > > >> Hi, > >> > >> With h264-mt having now landed, I think we are about ready to branch of > >> 0.7. If anyone has another important change pending, now would be an > >> excellent time to reply to this post ASAP. > >> > >> With the release approaching, let us consider how to properly tag the > >> release and the commit that is used as base for the release branch. > >> > >> Option a: > >> - tag the branchpoint '0.7' > >> - create a new branch 'release/0.7' > >> - commit a RELEASE file '0.7rc1' as first commit > >> - use that to roll a rc1 tarball > >> - cherry pick changes necessary > >> - do the first release as '0.7.1' > >> > >> Pros with this approach: > >> - no freeze necessary, development in master can continue (this is the > >> mode we've used for 0.6) > >> - the version numbers of master continue to increase: git-0.7-1, > >> ... git-0.7-50, git-0.7-100, etc. > >> > >> Cons with this approach: > >> - on might it find misleading that the tag '0.7' does not constitute > >> the '0.7' release. > > > > I find this option unacceptable. Tags must never lie. > > > >> Variant of Option a (Let's call it a'): > >> - tag the branchpoint '0.7' > >> - create a new branch 'release/0.7' > >> - commit a RELEASE file '0.7rc1' as first commit > >> - use that to roll a rc1 tarball > >> - cherry pick changes necessary > >> - do the first release as '0.7.0' > >> > >> Cons: > >> - Potential confusiong between '0.7.0' and '0.7' > >> > >> Option b: > >> > >> - tag the branchpoint '0.7.0' > >> - create a new branch 'release/0.7' > >> - commit a RELEASE file '0.7rc1' as first commit > >> - use that to roll a rc1 tarball > >> - cherry pick changes necessary > >> - do the first release as '0.7.1' > >> > >> Pros with this approach: > >> - no freeze necessary, development in master can continue (this is the > >> mode we've used for 0.6) > >> > >> Cons with this approach: > >> - the version numbers of master continue to increase: git-0.7.0-1, > >> ... git-0.7.0-50, git-0.7.0-100, etc. > >> - people might be confused that git-0.7.1 might be 'higher'/'better' > >> than git-0.7.0-250 (*) > > > > That numbering is weird. Having both 0.7 and 0.7.0 tags will only cause > > confusion. > > > >> Option c: > >> > >> - announce a week of freezeing > >> - development focuses on fixing regressions only > >> - tag '0.7' in master > >> - create a new branch 'release/0.7' > >> - commit a RELEASE file '0.7rc1' as first commit > >> - use that to roll the 0.7 release tarball > >> > >> Pros with this approach: > >> - process is more(?) straight-forward > >> - the version numbers of master continue to increase: git-0.7-1, > >> ... git-0.7-50, git-0.7-100, etc. > >> > >> Cons with this approach: > >> - freeze necessary, development in master is slowed down > >> - people might be confused that git-0.7.1 might be 'higher'/'better' > >> than git-0.7.0-250 (*) > > > > I don't mind a short freeze of master at all. People can still develop > > in their local branches, just like they already do (hopefully). > > > >> The issues marked with (*) could be mitigated by doing a 0.8b1 release > >> before the 0.7.1 point release. > >> > >> I wonder how strongly people feel about c. In the discussions about > >> the release processes during the 0.5 and 0.6 releases, > > > > We were using svn then, and a freeze would have had a much greater > > impact on developers. > > > >> I had the impression that freezing trunk at that time was not very > >> much welcomed among developers; has this changed in the mean time? > > > > We got rid of the ones who opposed the very notion of releases, let > > alone a pre-release freeze. > > > > Do we have a list of important issues to fix before the release? > > AFAIUI, there are some libx264 wrapper option changes pending, Alex, > Anton, could you please propose something that we can push into 0.7, and > deliver the proper fix for 0.8 or if possible, for 0.7.1? > > What else do people really care about for having in 0.7? I would like to have 10-bit H.264 assembly included. Right now it is almost unusably slow. I will probably have the code finished in under a month and a half.
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
