Tom,
perfectly resumed !
So:
cvs co jboss
cvs tag 2_3_0
cvs tag -b 2_1
cvs co -r 2_1
cvs tag 2_1_0
would be the way to go...
Marc ?
Simon
> -----Original Message-----
> From: Tom Cook [mailto:[EMAIL PROTECTED]]
> Sent: giovedi 8 marzo 2001 0:56
> To: JBoss-Dev
> Subject: RE: [jBoss-Dev] VERSIONS & BRANCHES
>
>
> On Wed, 7 Mar 2001, Bordet, Simone wrote:
>
> There seems to be a lot of confusion about what exactly everyone is
> proposing here, so please allow me to summarise what I think
> are the best
> points of each.
>
> * Development of new features is done on the trunk. Commits
> here require
> no tagging.
> * When the release manager (marc?) is happy with the features in the
> trunk, a branch is created for the next version (say, 2_4).
> * When the release manager is happy with the stability of the branch,
> a new release is tagged, say 2_4_0.
> * Every time a developer commits a patch on that branch, he
> must re-tag
> it, say as 2_4_1, AFTER ensuring the tests all run correctly.
> * Every time a developer commits a patch on a branch, he must
> consider, in
> consultation with other developers, whether it is needed in the
> trunk, and if so apply it there. *Carefully*.
> * Similarly, when a developer commits a bug-fix (NOT new
> feature) on the
> trunk, he must consider whether it is required in the branch for
> the latest release.
> * Old branches die when a new branch is created.
>
> That way we don't end up with messy 'stable' or 'patches'
> tags, don't have
> horrible tags like the 'rel_2_4_build_20013007' or some such
> which someone
> suggested (can you imagine typing that regularly? no tab completion
> here...), and it's simple enough that people might actually stick to
> it. Since there is no real central control over the
> repository, this is a
> significant consideration. If something is too complicated,
> people will
> just do it their own way, which is easier and non-standard.
> My signature
> is in fact a restatement of this principle.
>
> My HO.
>
> Tom
> --
> "If you mess with something for long enough it will break."
> - Schmidt's law of engineering
>
>
