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:[EMAIL PROTECTED] > 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 ([EMAIL PROTECTED]) > > > > -- > > > > On Wed, 13 Aug 2003 21:27:26 -0700 (PDT) > > (Subject: Re: [combo] Commons Core release?) > > "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > > > > > Comments interspersed. > > > > > > On Thu, 14 Aug 2003, Henri Yandell wrote: > > > > > > > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT) > > > > From: Henri Yandell <[EMAIL PROTECTED]> > > > > Reply-To: Jakarta Commons Developers List <commons- > [EMAIL PROTECTED]> > > > > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
