Public repository for post-6.5 development (PROPOSAL)
A proposal for a new convention for separating bug fixes from future feature development from release-specific changes, taking advantage of Mercurial's strong merge support.
Traditionally in NetBeans development, the "trunk" was where most things happened. When it came time to feature freeze a release, only bug fixes were permitted in trunk. A release branch would be created only after code freeze (i.e. in high resistance mode), releasing trunk for new work.
The justification for closing trunk for new features was that most developers should be concentrating on bug fixes, and merging changes to a branch in CVS is tedious and error-prone. This was also true for fixes made in high resistance, but these are not so numerous.
The same style was carried over after the switch to Mercurial for NetBeans 6.1, although Mercurial's merging facilities are much stronger than those of CVS.
This proposal is to use Mercurial branches more effectively. Although it could apply to any release cycle, for purposes of example NetBeans 6.5 will be discussed. It is assumed that the next major release is "7.0".
The Mercurial server should host these repositories:
- main, as today.
- post65, initially just a clone of main, with the same access rights.
- release65m2, release65beta1, ..., release65 which will contain the ultimate codebase for 6.5-related releases.
Bug fixes will be done in main. main will be routinely merged into post65. (This could be done manually, but should be easy to set up as an automated process.) main will also be routinely merged into release65 or whatever the active release-related branch is.
New feature development after feature freeze, intended for 7.0, may be done directly in the post65 repository. This should have quality expectations comparable to main before feature freeze: not everything need be perfect but it should basically work and not regress anything important. Of course individual teams working on experimental changes too dangerous even for this repository should create their own branches.
There should be few direct pushes to release65, and very likely only selected people should have push permission. Any changes pushed directly here are intended for the 6.5 release but not for future releases. These could include:
- 6.5-specific branding
- turning off assertions or other dev-build-like flags
- disabling or deleting modules or features which were found to be too buggy to release yet
- unpleasant workarounds for bugs which can be fixed in a better but riskier way
No one should merge release65 into main or post65; no one should merge post65 into main or release65. It should be straightforward to guard against such accidents. For example, to prevent post65 from being merged into the others, just identify one changeset which was pushed directly into post65; then set up a pretxncommit server hook applicable to the main and release65 repositories which rejects any attempt to push a set of changesets including this one. (You can always hg transplant a particular patch from any repository to any other if you need to.)
At some point 6.5 will be considered "done". At this point, release engineers should:
- do a final merge main -> release65 to get the last bug fixes
- push post65 -> main (no merge should be required since main was always being merged into post65 already)
- delete the post65 repository
- declare main open to 7.0 development
For the timing of this switch, there are a couple of options:
- Do the switch at code freeze, when only showstoppers are still being considered for 6.5. High-resistance (HR) fixes before then would be made in main just as before HR.
- Do the switch upon entering HR. HR fixes should then be made in the new post-6.5 main and transplanted to release65 as we do today. This is somewhat less attractive since transplant is inferior to direct merging (more error-prone). However it does permit fixes to be tested in main before being transplanted, which may be desirable.
Other possible models
There are a couple of variant models for how to name the repositories. The structure is essentially the same but the names may be important to people.
Logical style ("branch to stabilize")
main is always for new feature development, period. At feature freeze time, a branch is created, e.g. release65-fixes, and some time later some release "branding" branches such as release65. release65-fixes is merged into main and release65.
Advantage: easy to understand what main is for; no switching of meaning of repositories. Disadvantage: a change for average developers from what we did in the past; some risk that people who don't ever read their email would innocently keep on pushing bug fixes into main and wonder why they never made it into the release.
JDK style ("freeze and copy")
release65-dev is for 6.5 fixes. A clone is made named release70-dev as soon as 6.5 is feature frozen. release65-dev is merged into release70-dev and release65.
Advantage: you can see which NB release corresponds to which repository. Disadvantage: average developers will need to switch which repository they push to, at some time during every release cycle.
For average developers, there is no real workflow change under this proposal. As of 6.5 feature freeze day, you are only allowed to push bug fixes, no new features.
For developers working on new stuff destined for 7.0, you just need to clone post65 (i.e.: clone main then pull from post65) and push your stuff to it.
For RE and developers doing branding-related fixes, you just need to clone release65 (i.e.: clone main then pull from release65) and push your stuff to it.
Effect on continuous/periodic builders
The trunk build would probably continue to use main. There could be a separate build of post65 if desired ("bleeding-edge" dev builds). TBD if installers would be needed; probably just a basic ZIP would suffice, maybe with NBMs. Can run basic commit-validation but need not run elaborate tests.
The nbms-and-javadoc build could be switched to post65 (plus contrib). This would make it always be building the newest available code, stable or not. We should disable the development update center in main (and after merging this change to post65, reenable it in post65 only).