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. 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 (*) 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 (*) 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, I had the impression that freezing trunk at that time was not very much welcomed among developers; has this changed in the mean time? If not, I'd slightly prefer a over b. So, let the bikeshed discussions begin! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
