commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [combo] Commons Core release?
Date Thu, 14 Aug 2003 16:25:25 GMT
The versioning scheme below seems too tricky to me. The
major-minor-maintenance framework is nice and simple on top of being well
known. This reminds me too much of Oracle version numbers and looking at
components versioned 7.2.3.4.11.3 (not kidding). 

When a sub-component is released, we just bump the corresponding version
component. For example we have combo-1.0.0 and lang-2.0 comes out (after
lang-1.0.1), we then get combo-2.0.0. Then codec goes from 1.1.0 to 1.1.1,
so we get combo-2.0.1. You do get version inflation, but this reflects the
meaning of major, minor and maintenance *truthfully* IMHO.

Detail, I guess that if lang-2.1 comes up (after 2.0), you would go from
combo-2.0.1 to 2.1.0 (not 2.1.1).

Gary

> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Thursday, August 14, 2003 04:31
> To: Jakarta Commons Developers List
> Subject: Re: [combo] Commons Core release?
> 
> 
> Not sure. I think any combo release should be driven by a release of a
> sub-component. Versioning of the combo release gets a bit interesting
> then, probably we should have the idea of:
> 
> super-major-minor-bugfix
> 
> ie) 1.1.1.1
> 
> When Lang 2.0 comes out, it would move to 1.2.1.1. When Codec 1.1.1 comes
> out, it would move to 1.2.1.2 etc.
> 
> Hen
> 
> On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
> 
> >
> > By the way, how about
> > "Commons-Core_August_2003" or something equivalent to it,
> > rather than "Commons-Core V1.0" ... ??
> >
> > We are taking the list of "Products available as of the end of ***,
> > year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
> > would be ideal and make sense .... Comments please ;-)
> >
> > -- Tetsuya (tetsuya@apache.org)
> >
> > --
> >
> > On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
> > (Subject: Re: [combo] Commons Core release?)
> > "Craig R. McClanahan" <craigmcc@apache.org> wrote:
> >
> > > Comments interspersed.
> > >
> > > On Thu, 14 Aug 2003, Henri Yandell wrote:
> > >
> > > > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> > > > From: Henri Yandell <bayard@generationjava.com>
> > > > Reply-To: Jakarta Commons Developers List <commons-
> dev@jakarta.apache.org>
> > > > To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> > > > Subject: [combo] Commons Core release?
> > > >
> > > >
> > > > Last November [I think] Craig created the Combo project. It puts a
> whole
> > > > lot of Commons projects into one jar and makes them available in a
> much
> > > > simpler form to users.
> > > >
> > > > This is the biggest complaint about Commons at the moment [I think],
> that
> > > > we have some kind of reproduction of jars going on in which more and
> more
> > > > jars appear in the user's code.
> > > >
> > >
> > > That was one issue.  Another was the potential for having different
> > > packages require different versions of the same commons package.
> > >
> > > > I'd like to consider a release as such from Combo of what some of us
> were
> > > > calling Commons Core a while back. It's an implementation of the
> Combo
> > > > ant-scripts [currently I copy and paste, but it shouldn't be hard
> for me
> > > > to make a single build.xml and a shared properties file per
> > > > 'distribution' with enough Ant learning].
> > > >
> > > > My current criteria is that Commons Core _only_ depends on JDK1.4
> [and
> > > > cross-dependencies inside the distribution]. Currently I have:
> > >
> > > Trying to define "combo" as anything other than "the latest released
> > > version of every Commons package" seems like it's guaranteed to cause
> > > arguments.  The collection you propose below, for example, is totally
> > > useless to me and all the projects I work on.  But commons-combo as it
> is
> > > currently built would be useful to me, and to you, and to anyone else.
> > >
> > > >
> > > > =====
> > > > Apache Commons Core v1.0 consists of:
> > > >
> > > > Jakarta Commons BeanUtils 1.6.1
> > > >     Makes the JavaBean specification easier to deal with.
> > > >
> > > > Jakarta Commons CLI 1.0
> > > >     A command line interpreter. Used to handle all the flags passed
> to your
> > > > program on the command line.
> > > >
> > > > Jakarta Commons Codec 1.1
> > > >     Common encoders and decoders.
> > > >
> > > > Jakarta Commons Collections 2.1
> > > >     Many more implementations that fit the Collections API.
> > > >
> > > > Jakarta Commons Lang 1.0.1
> > > >     Enhancements to classes found in java.lang.
> > > > =======
> > > >
> > > > A url to a build is: http://www.apache.org/~bayard/commons-core/
> > > >
> > > > I'm doing some trickery to turn BeanUtils' commons-logging
> dependency into
> > > > a JDK1.4 util.logging dependency. It would be nice to add Pool,
> HttpClient
> > > > and maybe Net [with some regexp trickery] and consider that a
> version 1.0.
> > > >
> > >
> > > We can talk about that on a [beanutils] specific thread, but I'd be -1
> on
> > > doing this to the real BeanUtils code.  A very large number of
> BeanUtils
> > > users do not have the luxury to run on a 1.4 JDK.
> > >
> > > > Issues I forsee
> > > > ===============
> > > >
> > > > *) Combo has never been voted into Commons-proper. How do we handle
> this?
> > > > It's not a new codebase but a release mechanism.
> > > >
> > >
> > > It should be voted as a formal package (with a defined release
> mechansim
> > > like "every time an included package rolls a new release, then roll a
> new
> > > combo release as well.")
> > >
> > > Of course, this is going to run into difficulties if/when included
> > > packages start making backwards-incompatible API changes (like on
> version
> > > 1.x to version 2.x transitions), but so far Commons developers have
> been
> > > pretty sensitive to that.
> > >
> > > > *) Arguments over what goes in what. Rather than create a huge jar
> of
> > > > everything, which I think is unpalatable to the user, I chose the
> JDK 1.4
> > > > dependency as a strict guideline and tried to make things toe the
> line.
> > > > Effectively it's a Commons-J2SE distribution for adding features to
> a
> > > > new J2SE install.
> > > >
> > > > *) Testing. In Core 1.0 I've chosen the latest stable releases
> [except
> > > > HttpClient which is at RC2] of each project. There are no
> > > > interdependencies, but as projects depend on each other the building
> of a
> > > > combo jar becomes trickier. This is a problem for the future
> probably.
> > > > Possibly the solution is that after each component is built/tested,
> and
> > > > the new uber-jar is built, the tests should be re-run against that
> jar.
> > > >
> > > > ====
> > > >
> > > > My general idea for Combo is that it is a tool for creating
> distributions
> > > > of Commons code. These distributions are effectively configurations
> of
> > > > Combo. I'm not sure if Craig is +1 or -1 for this and what his
> > > > original plans were, but I think there's a need for a solution and
> that
> > > > this is a solution.
> > > >
> > > > No idea if it's a good solution :) It seems quite fun and
> interesting.
> > > >
> > > > Any ideas? Flames?
> > > >
> > > > My chief two concerns are:
> > > >
> > > >
> > > > 1) Can I treat Combo as a Commons Proper project.
> > > > 2) Is the idea of a Commons Core distribution viable.
> > >
> > >
> > > I'm -1 on subsetting commons-combo to be less than a combination of
> all
> > > released Commons packages.  Trying to say what things are "core" and
> what
> > > are not is just fodder for flamewars.
> > >
> > > I'm +0 on setting up the combo build.xml file in such a way that you
> can
> > > do your own custom subsets.
> > >
> > > >
> > > >
> > > > Hen
> > >
> > > Craig
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message