Craig L Russell wrote:
On Sep 13, 2006, at 12:06 PM, Allen Gilliland wrote:
That sounds right to me, but I think branches/roller_2.x makes more
sense. It's just a matter of convention, but I think that 2.x
suggests that it's the ongoing branch for 2.x development, if there is
any.
We should probably have a little bit of discussion about what we want
for the standard way of trunk -> branch -> tag process. I don't think
we have followed any strict conventions up until now, and it would be
nice to actually do that.
I suggest the repository is used like this ...
trunk - do main work here
branches/roller_3.0 - only used during RC phase for a release, becomes
a tag when RC is approved.
branches/whatever - used when development can't be done in trunk.
i.e. branches/roller_3.1_tagging or branches/roller_jdobackend
tags/roller_X.x - final resting place for releases. these never change.
+1 generally. What I think is missing is how to handle minor revisions,
e.g. 3.1. Proposal detail below...
So the release process is ...
1. do some amount of work in the trunk.
2. you think that it's worthy of release and copy trunk to a branch
with release number and create an RC from that branch.
3. community evaluates and votes on that RC.
4. if changes are needed they are done to the trunk and merged into
the branch, then a new RC is created and we go back to step #3.
5. when an RC is approved by the community the branch is moved to a
tag and the release goes out.
6. Continuing development on a release is done by creating another
branch, e.g. svn copy ...branches/roller_3.0 .../branches/roller_3.1
7. Some fixes are merged from trunk into branches/roller_3.1 and other
fixes are applied directly if they are not applicable to trunk.
Repeat from 3 for release of 3.1
True, but I think the trunk should always represent the next release of
Roller. So once 3.0 goes public then the trunk should represent 3.1 in
development. Once we think 3.1 is done we copy trunk ->
branches/roller_3.1 and go through the RC process.
However, your point is very valid in the case of patches which need to
be done on old releases. i.e. if we wanted to do a patch release for
Roller 2.2 for some reason. in that case i suggest that the 2.2 tag
should be the starting point for the release and should be copied to a
new branch used for the patch, then that branch is used to develop and
release the patch. so ...
1. cp tags/roller_2.2 branches/roller_2.2.1
2. make changes for patch in branches/roller_2.2.1 and do RC process
3. when RC is approved we move branches/roller_2.2.1 to tags/roller_2.2.1
-- Allen
this way when a release is at the RC stage the trunk is still free for
further development which does not have to affect the branch used for
creating the release. then the tags are just for archiving purposes.
i am open to any changes in this process, i mainly just want a
documented process so that anyone could follow the steps and know
exactly what to do. i also think this makes sense because it keeps
the repository clean so it's easy to know what's being used and how.
some things that seem worth fixing to me are ...
tags/roller_2.2_scrapped/
tags/roller_2.4_alpha1/
neither of those are *final* releases, so i'm not sure why they are
tagged. i think it's easy to just say, tags are only releases that go
public, everything else is a branch. also, we don't have a roller_2.1
tag, which is not cool :/
branches/roller_2.3/
do we still need that for something? i would think that after a
release goes public it's branch is no longer needed because work
continues in the trunk, or if it was the last in a major rev then work
continues in the .x branch for that major rev.
anyways, what do you guys think?
I'm not exactly clear on the difference between a branch and a tag.
IANASE (I am not an svn expert)
Craig
-- Allen
Dave Johnson wrote:
Yes, I'd like to make Roller 3.0 the trunk as soon as possible.
Anybody object to this?
1) move trunk to branches/roller_2.4_unreleased
2) move branches/roller_3.0 to trunk
- Dave
On 9/13/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
any reason why we can't do this now?
-- Allen
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
