Hi,
>
> Let's keep it simple.
>
> 2.3.build, build being incremented everytime a new feature or
> bug fix is
> built in, seems like a reasonable plan
>
> The only difficulty with the "build" is when people are doing stuff in
> parallel. I guess there will be a "file not up to date"
> thing ... so it
> would work.
>
> Ok, so 2.1 is out... let's branch for new development... As I
> asked let's
> not commit new stuff in 2.1.
>
Don't you mean 2.1 is the branch and the mainline trunk is the new (2.3.1)
stuff? In general people will be working on the mainline and thus it seems
safer to make this the default - people have to specifically get 2.1 and
that branch?
> Can someone more knowledgeable than me in "branches" take
> care of tagging
> 2.1 and branching for the new development with 2.3.1
>
I could do this - if your happy with what I just said, so specifically.
tag where we are now as 2.1.0
Also create a branch 2.1.0-patches - which is what patches will be applied
to ontop of 2.1.0 - we can then baseline a release on this branch if/when we
want to (ie 2.1.1, 2.1.2 etc). Obviously patches on the branch will need to
be applied to the main trunk - as appropriate.
About going forward - a tag per check in seems OTT - every few weeks seem
more appropriate - unless we are talking about specific patches to a
release.
See MINI-CVS-JBOSS-HOW-TO below
> Again numbering:
>
> major, minor, build is tried and true. build in our case is the
> responsability of every developer that commits something,
> meaning a patch or
> a feature.
>
> Regards
>
> marc
>
HTH,
Chris
MINI-CVS-JBOSS-HOW-TO
Situation 1: generally done by all developers - as its done now
Doing a new feature/patch to the main app - ie working on 2.3.
1) Get the latest code from CVS (ie HEAD)
2) Make/test your changes
3) check in the changes
Situation 2: done by a few "release managers" on an ad-hoc basis every few
weeks
Making a release (eg 2.3.0)
1) Get the latest code form CVS (ie HEAD)
2) run all tests - check they work ok
3) tag jboss (2.3.0) and create a patch branch (2.3.0-patches)
Situation 3: could be done by any developing patching a release
Patching a release (eg 2.3.0-patches ) - cos a fix is needed for it
1) get the patch branch - 2.3.0-patches
2) make/test changes
3) check in the changes
4) tag branch (2.3.1) and create patch branch of this (2.3.1-patches)
5) [optionaly] apply these changes to the main HEAD trunk - if needed
================================================================================================
This electronic message (email) and any attachments to it are subject to copyright and
are sent for the personal attention of the addressee. Although you may be the named
recipient, it may become apparent that this email and its contents are not intended
for you and an addressing error has been made. This email may include information that
is legally privileged and exempt from disclosure. If you have received this email in
error, please advise us immediately and delete this email and any attachments from
your computer system.Rabobank International is the trading name of Coöperatieve
Centrale Raiffeisen-Boerenleenbank B.A. which is incorporated in the Netherlands.
Registered with the Registrar of Companies for England & Wales No. BR002630 and
regulated by the SFA for the conduct of investment business in the UK.
The presence of this footnote also confirms that this email has been automatically
checked by Rabobank International for the presence of computer viruses prior to it
being sent, however, no guarantee is given or implied that this email is virus free
upon delivery.
