On 29/03/14 21:56, Vaclav Petras wrote:
Inspired by what code sprint people were saying, I put together my proposal. It counts with release once a year and a half year bugfixing (feature freeze) period before the release. I expect comments and criticism and I would be glad to compare this proposal with some other proposal.Vaclav Releasing and branch management should follow these steps: 1. have trunk 2. fork release branch , e.g. release_7_1 3. only bugfixes to release branch, new features (additions, refactoring, documentation) only to trunk 4. release new version based on release branch, , e.g. 7.1.0 5. only critical bugfixes go to release branch, release patched version if needed, e.g. 7.1.1, .7.1.2 6. fork a new release branch (e.g. release_7_2), set old release branch to readonly and continue with point 3. It seems that release should be done every year. A new release branch should be forked half a year before planned release.
I find that 6 months is a fairly long period to maintain a bugfix-only branch. I would rather propose to either branch later, or to allow more than just bugfixes into the release branch for 4-5 months before going into bugfix-only phase for the last month or two. During the first period new features can be ported to the release branch once they have had some testing in trunk.
Moritz _______________________________________________ grass-psc mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-psc
