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? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
