jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Delagrange, Morgan" <mdela...@us.britannica.com>
Subject RE: cvs commit: jakarta-taglibs HOWTO-RELEASE
Date Mon, 16 Apr 2001 14:30:36 GMT
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:nacho@siapi.es]
> Sent: Saturday, April 14, 2001 11:41 AM
> To: 'taglibs-dev@jakarta.apache.org'
> 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
> 

Mime
View raw message