Craig L Russell wrote:
Just a few comments on the picture. Basically it's fine and
consistent > with good engineering practice, and consistent with other
projects at > Apache.
I've seen other projects use slightly different terminology and
naming > schemes. Instead of maintenance, the term branch. Instead of
release_2.1, just 2.1. So you would have a root/trunk with continuing
development; root/branches/2.1, root/branches/2.2, root/branches/3.0
for development and maintenance; with root/tags/2.1.0,
root/tags/2.1.1, root/tags/2.2.0, root/tags/2.2.1 frozen after
release.
I like the short notation for the /root/tags/m.n.r but prefer not to mix
the sustained development with the /branches which I prefer to keep for
whatever ad hoc purpose we need to branch, I also like the short
notation for the sustained development.
I get the feeling that /branches represent what I used to call our
/skunk branch (named after skunkworks) where no strict development
policies apply and I think that a uniform policy should apply to each
branch (besides the /branch branch) and therefore no mix of ad hoc
branches with sustained development.
Below my adjusted preference, I feel we are getting close ...
/trunk
|
|
|---------- /maintenance/2.1/
| \
| \
| \
| \ ------- /tags/2.1.0/
| \
| \
| \
| \ ------- /tags/2.1.1/
| \
|
|
|
|--------- /maintenance/2.2/
| \
| \
| \ ------- /tags/2.2.0/
| \
|
|
|
|
|--------- /maintenance/3.0/
| \
| \
| \ ------- /tags/3.0.0/
| \
|
B.T.W. Jim when do you expect to bring Confluence to live so that we can
add this kind of conventions.
--
Mark
