jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <mdela...@yahoo.com>
Subject Re: cvs commit: jakarta-taglibs HOWTO-RELEASE
Date Mon, 16 Apr 2001 15:32:49 GMT

--- Glenn Nielsen <glenn@voyager.apg.more.net> wrote:
> 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.

OK, no problem.  Just as long as we're actually
_going_ to branch, I won't quibble.

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

OK.  Do we have a volunteer?

> 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?

Not sure I follow you here.  Are you suggesting that
the nightly builds will be performed on all releases
and not just the main trunk?  Do we need to do that?

> 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  |  */      
>                 |
>
----------------------------------------------------------------------


=====
Morgan Delagrange
Britannica.com

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Mime
View raw message