On May 31, 2005, at 1:37 PM, Bill Stoddard wrote:
Geir Magnusson Jr. wrote:
Can we agree that we need to somehow construct the stable,
unstable and sandbox codebases?
If so, can we move on to how?
geir
Check out the httpd project:
http://svn.apache.org/repos/asf/httpd/httpd/
essential features:
'trunk' is 'development' (unstable) reporitory. It is constantly
moving forward under loose rules for what can be committed.
'branches' contains the 'stable' code. httpd 2.0.x (and 1.3.x)
constantly move forward but under a 'review-then-commit' policy.
All code that goes into the stable branch must be reviewed and
voted on before it can come into the stable branch.
'tags' contains all the tagged releases
http://svn.apache.org/repos/asf/httpd/httpd/branches/
So using this model, one of the geronimo branches could be 1.0.x.
When 1.0 is 'done', tag the release and continue on the next
'stable' drop, migrating function out of trunk and into 1.x using
whatever process you like (RTC, CTR, votes, whatever). The RTC +
vote policy httpd 2.0.x uses may be too restrictive for geronimo
1.0.x, so do whatever makes sense for this project.
There will come a day when you want another stable branch of
geronimo (presumably forked from trunk). When that day comes, just
create a new tree under 'branches', named differently (maybe 2.0.x
or 1.2.x, whatever).
I know this doesn't really answer the more interesting question
about how to structure the repository to support assemblying
components into a 'custom' install.
I'm not sure that's important here - we should be able to assemble
any custom install from parts wherever they are - we can have
assemblies in both stable an unstable... The key is that the code in
stable remain so.
I'm not sure I'm a fan of going to the full degree of "review-then-
commit" right now (but probably in the future when we run 70% of the
worlds J2EE app server installations ;) but now a "propose then
commit" for stable branch might be nice.
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
