jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: cvs commit: jakarta-taglibs HOWTO-RELEASE
Date Mon, 16 Apr 2001 15:09:31 GMT
Morgan,

Thanks for taking the initiative to write up the How to Release document.
I agree nacho about how CVS should be used for branching releases.

Plus we need to document the structure of a tablibs directories and
files so that it works with the automated build and documentation scripts.

There is a great deal more work that needs to be done to do this right.
The scripts that build the jakarta-taglibs site will have to know the
difference between a release version and the current development version.
Who runs the crontabs for building the jakarta-taglibs site, Justyna?

Your timing was good, Pierre recently sent me the message below.

Pierre Delisle wrote:
> 
> Ted, Glenn,
> 
> I think it is greatly time (as was already hinted by Glenn last month)
> to get some more organization in jakarta-taglibs.
> 
> I don't mind driving it, but first I'd need some feedback from you
> two.
> 
> Ted, you're heavily involved with jakarta-commons. Anything we can
> leverage from there since the two projects have a lot in
> common (punt intended :-)).
> 
> Glenn, since you wrote the message below, do you already have
> ideas/content to contribute for 'ze' process?
> 
> Below are some ideas regarding a taglibs "dashboard".
> Let me know what you think.
> 
> Thanks,
> 
>     -- Pierre
> 
> ---------------------------------
> Here are some thoughts on how we could improve the tracking of the various
> libraries in jakara-taglibs.
> 
> (haven't polished it yet, just to get your quick feedback)
> 
> Currently, the home pages of taglibs do not contain much information.
> I'd like to suggest we replace these home pages with the concept
> of a dashboard that gives a quick overview of all that's available
> in jakarta-taglibs, along with short description, status info, and
> links of interest.
> 
> The taglibs would be listed according to their status,
> in alphabetical order.
> 
> status:
> 
> - released
>     ready for prime time
> - beta
>     almost ready for prime time
> - experimental
>     ... still in experimentation phase and looking for feedback
> 
> 
> You start as experimental
> get feedback from people...
> go to beta...
>   have people signed up to use it...
>   have test plan...
>   polish docs...
> then get voted on and released
> 
> Each library has the following info in the table:
> - name
> - version
> - date
> - links to docs, binary, source
> - short description
> - Committers
> 
> For example:
> 
> -----
> Released Tag Libraries
> 
> JDBC   Version 1.0 - 2000/12/23  Docs  Binary  Source
> Committers:
> This library ....
> 
> Scrape Version 2.3 - 2001/04/13  Docs  Binary  Source
> Committers:
> This livbrary ....
> 
> -----
> Beta Quality Tag Libraries
> 
> ...
> 
> --------------------------------------------
> Glenn Nielsen wrote:
> >
> > Jakarta-taglibs has had a number of tag libs contributed and released
> > in the last 6 months, but from what I can tell, there is no documented
> > process for releasing a taglib and getting it published to the website.
> >
> > There needs to be a HOWTO-RELEASE document in jakarta-taglibs that documents
> > what files a taglib needs to have in place in order to be published to
> > the website and how to officially relase a taglib.  It would be nice
> > to have a NEWS section on Jakarta-taglibs so News about recent
> > taglib releases could be listed.
> >
> > Finally, a way to freeze (branch) a taglib so that work can continue
> > on the taglib while still having a stable released version.
> >


> "Delagrange, Morgan" wrote:
> 
> 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
> >

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Mime
View raw message