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:[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
> >
--
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
