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? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
