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 <[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]
