Hey,
(BTW WinCVS 1.2 is out at www.wincvs.org, looks great).
I worked and I'm currently working with branches, so I can give my ideas
here.
The main trunk should hold the "new features". A parallel branch should hold
the "stable" versions.
We have now 2.1-PRE.
Let's create a branch called 2.1_stable, a tag on the branch called 2.1.0
(the branch root code), and a tag on the main trunk called 2.3.0. Every bug
fix on the branch will increment the last digit, as suggested (the same on
main trunk, also for new features).
Every bug fix on the branch MUST be reported on the main trunk. For this
great care is needed, and a lot of inter-developer communication (between
those working on the main trunk and those on the branch).
At a certain point we are ready for a new binary (2.2.0), so we tag it on
the branch, and expose a binary on the web site.
Suppose now that the DTM (for example) is ready on the main trunk, and we
decide to have a new relase. We branch a 2.3_Stable and we tag on the branch
a 2.3.0, and we tag a 2.5.0 on the main trunk, then we go on as above (and
branch holding 2.1_stable and 2.2.0 will die).
"Stable" branches will die every time a new release is taken from the main
trunk.
Numbering:
binary will always have <major>.<even_minor>.<patch>;
CVS stables will have <major>.<minor>.<patch> where minor <= binary's
even_minor;
CVS develop will have <major>.<minor>.<patch> where minor > binary's
even_minor.
MINI-HOWTO:
1) Cheching in stuff on the main trunk: new features, bugs on new code, etc
a) checkout jboss module (cvs co jboss), no tags
b) do your changes
c) commit them
d) [optional] tag them
Beware that cvs update -A (resetting sticky tags) is somehow less safe
than a fresh checkout: CVS will not delete files you have in your local
directory if they have been deleted from CVS (in a previous commit), so you
end up with a mixed set of files.
2) Checking in a patch on the "stable" branch
a) checkout jboss module specifying the branch tag (cvs co -r 2.1_Stable
jboss): this will checkout the *top* of the branch (ie the most recent
changes to that branch). This is normally reason of confusion: you're not
checking out the code at the moment of the branching, but the most updated
one.
b) do your changes
c) commit them
d) [mandatory] tag the branch, incrementing the patch number (cvs tag
2.1.16 for example); this is vital to have easy merges to the main trunk
e) [mandatory] merge the changes to the main trunk if they're missing. Of
course if other developer already fixed this on the main trunk as part of
other changes the merge is not needed (but checking if it is needed is
mandatory)
f) [mandatory if e) was done] checkout the latest main trunk code (cvs co
jboss), no tags
g) [mandatory if e) was done] tag the main trunk (cvs tag 2.3.28 for
example); this is also useful to track which files and when have been merged
and if something went wrong we have tags to figure it out.
3) Creating a binary (IMHO this is best done from branches)
a) checkout the latest branch code, as 2a above (cvs co -r 2.1_Stable)
b) run all the test
c) tag the branch with an even minor release (cvs tag 2.2.0)
d) if the even minor release is less than the current minor release on
the main trunk, do nothing; else
I) checkout the latest main trunk code (cvs co jboss), no tags
II) tag the main trunk with the successive odd minor release (cvs tag
2.5.0)
For example we have 2.1_Stable on branch and 2.3.x on main trunk; we
add lots of bug fixes on the branch; we create binary 2.2.0; we add more
patches on the branch, until 2.2.85; then another binary is needed, so we
create 2.4.0 *on the branch* *AND* we tag the main trunk with 2.5.0.
Any comment ?
Simon
