Hi Frank,
Just for reference purposes I think it might be handy to describe the
versioning policy I believe there is/was in place for the JTSK codebase,
correct me if I'm wrong. Assuming each Apache River deliverable has a
version number of:
m.n.r
m = major version
n = minor version
r = maintenance version
The major version number should only be increased in case of major
changes that might introduce compatibility problems or represent some
fundamental improvement such as with the introduction of Jini ERI and
all the security features (JTSK 1.2 to 2.0).
The minor versions reflect the various feature releases and the last
part of the version number reflects the maintenance release.
I'd prefer to see the "tags" area remain a "golden", reference-only
area for official releases to avoid mixing pre-release working
copies with official releases in the same area. If we really
Totally agree.
need a pre-release working copy to allow newer work in the trunk,
I'd suggest that we create a release-candidate branch in a separate,
top-level, "release-candidates" directory.
I believe there is always a need to branch when (almost) feature
ready in the trunk for a planned but not yet ready to release the
'release'. This would be the point where you release your beta to be
tested by the larger audience. No doubt this will result in feedback
that has to be accommodated in the final release. And it always takes
some time to get the 'paperwork' done for a release and I think we
shouldn't have people waiting to continue working in the trunk.
For those who may not be aware, Subversion does not have a labeling
mechanism. Copies from specific repository revisions are used to
create named (ie, "tagged") snapshots. Branches are also just copies.
In the case of sustained work for previous releases, we could branch
off of a tagged release, placing the working branch in a "sustaining"
directory (eg, sustaining/release_3.0.1_work). When the sustained
work is released, a tagged copy would be placed into the official
"tags" area (eg, release_3.0.1).
Obviously, changes in branches (sustaining work, prototype work, etc)
that also apply to the latest work in the trunk or other sustaining
work can be merged appropriately on an as needed basis regardless of
where the working branches are located.
The release candidates and sustaining branches could easily go into the
"branches" area, but I suspect that area will quickly become cluttered
with all sorts of stuff of varying importance. I'd prefer a few specific
top-level folders.
To summarize the above, we would have the following:
/branches/ ## misc work
/release-candidates/release_{ver}_candidate
/sustaining/release_{ver}_work
/trunk/ ## "latest" work
/tags/release_{ver} ## only official releases
Moving the "release-candidates" and "sustaining" dirs under "branches"
would also be ok and would maintain the intent of a "branches" area. If
we did this, I'd also make a "branches/misc" area to prevent the clutter
I mentioned above. If we went with this option, the overall layout would
look like:
/branches/misc/ ## misc branched work
/branches/release-candidates/release_{ver}_candidate/
/branches/sustaining/release_{ver}_work/
/trunk/ ## "latest" work
/tags/release_{ver}/ ## only official releases
Comments?
I think we agree, except that I don't see the need to have both a
/branches/release-candidates/ and /branches/sustaining/ branch. When
feature ready one branches the trunk into maintenance mode and the trunk
will continue with getting new features for the next feature release
(one that increments the minor version). The moment the maintenance
branch is created one could ship a beta (or whatever you name it) and
from there any 'fixes' will be received in the maintenance branch (and
likely will be integrated into the trunk as well). Once we decide we are
ready for a final release we branch from the /maintenance branch into
the /tags branch. Sustained development for a particular release (for
which major and minor version doesn't change) is done in the maintenance
branch. Each new maintenance release will be branched from /maintenance/
into /tags/release_{m.n.r}
So ongoing development (latest and greatest) takes place in the trunk,
sustaining development for a particular release (m.n.?) will take place
in the maintenance branch. "Golden" reference only release are branched
in /tags/release_{m.n.r}/
/trunk
|
|
|---------- /maintenance/release_2.1/
| \
| \
| \
| \ ------- /tags/release_2.1.0/
| \
| \
| \
| \ ------- /tags/release_2.1.1/
| \
|
|
|
|--------- /maintenance/release_2.2/
| \
| \
| \ ------- /tags/release_2.2.0/
| \
|
|
|
|
|--------- /maintenance/release_3.0/
| \
| \
| \ ------- /tags/release_3.0.0/
| \
|
Applying the branching strategy as above will result in the ability to
keep the pace in the trunk without influencing the codebase that is
about to be released. My experience is that between feature ready and a
final release there are always these last minutes issues that pop up
need to be resolved, if not that is great, if so there is a place for it
by default.
--
Mark
