Hey,
> Yes please go ahead,
> Thanks for taking care of that,
Ah... Marc you're so good in choosing volounteers... ;)
But OK, I will take care of this.
> We need the following
>
> 2.2 branch current code with a FINAL tag (there is very
> little bitchin...)
> we will put a 2.2.1 if we need to with bug fixes.
>
> a 2.3 branch for development of new features.
You mean that you would like to exit with a 2.2 ASAP ?
Maybe it is worth to ask for a vote on jboss-dev if there is someone that
would like to commit some useful patch before 2.2 ?
> the "howto" is a very good idea,
I will first write this howto, post it to jboss-docs also (and to the web
site), then will go on with tagging / branching, OK for you ? (or you have
more urgency of releasing the 2.2 ?)
Simon
>
> marc
>
>
> |-----Original Message-----
> |From: Juha Lindfors [mailto:[EMAIL PROTECTED]]
> |Sent: Saturday, March 24, 2001 4:08 AM
> |To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> |Subject: RE: VERSIONS & BRANCHES
> |
> |
> |
> |Guys,
> |
> |now that we have the CVS up and running at SF, can we go
> ahead with the
> |branching plan?
> |
> |There's a slew of commits going in again, people are
> bitching about our 2.1
> |distros not being the same, we can't recreate them, etc.
> |
> |Simone, would you like to take this task? You seemed to have
> the best idea
> |how to go about this.
> |
> |If you do, before you do anything with the CVS, please
> please please please
> |write a detailed step by step howto for committers how to
> deal with the
> |branches, tags, etc.
> |
> |-- Juha
> |
> |
> |At 09:52 8.3.2001 -0000, Simone wrote:
> |>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
> |>>
> |>>
> |>
> |>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
