Elias Torres wrote:
Sounds good except for the part of tagging being a branch. :)
Tagging is not reworking any of the core just adding a feature. If so,
then everything should be coded as a branch. Modularization is a prime
candidate in my opinion for branching in case we want to do some work in
trunk with Roller.
Actually, I only used that as an example because of your previous
comment about making a branch for tagging. I agree, tagging shouldn't
need its own branch of development, it should ideally be done in the trunk.
IMO the only reason we should ever do development outside of the trunk
is if we are going to be working on something that has no reasonably
scheduled delivery date or if the work is such a massive change that it
would prevent others from being able to continue their work in the trunk.
So, as long as we are committed to tagging for 3.1 then i say we do it
in the trunk.
-- Allen
-Elias
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.
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.
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?
-- 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
