It doesn't matter that much to me. My only thinking here was if we decide to abandon a new release, we don't have to merge the old release into the main trunk. I assume you would prefer the alternative. I'll go ahead and change it in a little while, unless there are other objections.
Any other comments? Are we generally happy with these guidelines? If so, I think we should go ahead and prepare some releases.
> -----Original Message-----
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 14, 2001 11:41 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: cvs commit: jakarta-taglibs HOWTO-RELEASE
>
>
> Hola Morgan:
>
> > +Let's assume that the current release of your tag library
> > is 2.0.4, but you want to start work on 3.0. Here are the
> > steps you would take to start working on the new release:
> >
> > 1) Make an announcement on taglibs-dev
> > + 2) Create a branch called dev3 in CVS for the entire
> tag library
> > 3) Work on that branch
> >
> > (Note: it is a requirement that the main CVS branch in CVS
> > be the _current_ release, not a prospective release.)
> >
>
> ?�?�, i think this is the exact opposite to the current procedures
> everywhere in OSS projects using CVS ( at least the ones i know ).
>
> Currently, the normal procedure is to branch releases ( doing
> maintenance in that branch ), and continue developong on the HEAD
> branch, and i think it's a more natural way to work on CVS,
> and when the
> new release comes, only those bug changes on the branched release that
> affect the newer release are merged, not the oppositte that creates a
> bunch of ( dangerous ) administrivia when the next release becomes the
> lastest release.....
>
> Saludos ,
> Ignacio J. Ortega
>
