On 11/1/06, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
On Wed, 2006-11-01 at 11:59 -0500, Rahul Akolkar wrote: > Speaking of cross-commons, the JCL deps are all over the place. Which > is probably OK for now, since most variants are point releases (1.0, > 1.0.2, 1.0.3, 1.0.4 being popular ATM). > > Since JCL is the bottom rung of the ladder, we should do our bit and > move as one (i.e. if a component wants to up the JCL version, it > should be an [all] discussion, and all components should update trunk > such that their next RC matches up). We could restrict this to minor > or major release updates, but I don't see any harm in keeping the JCL > point release consistent as well. > > [ ] +1 Sounds reasonable > [ ] 0 > [ ] -1 Sounds unreasonable > > -Rahul > Rahul, Allow me to look at the situation from a different angle. I think what is definitely missing is a more formal and a clearly articulated product 'end of life' policy across all Jakarta. HttpClient, for instance, still mandates JCL 1.0.3 only, even though we recommend JCL 1.1 be used in production. Same goes for Commons Codec: 1.3 is preferred but only 1.2 is required, since there is no reason why HttpClient would not work with Codec 1.2. This way the project.xml captures an important bit of information: the oldest / least supported version of each individual project dependency. I would not want JCL level requirement be bumped up to 1.1 for no reason, as HttpClient works perfectly well with 1.0.3 or above. Having said all that I personally will have no issue of what so ever to put JCL 1.1 as a requirement for HttpClient 3.x the very same moment JCL 1.0.3 and 1.0.4 are declared 'end of life / support' by JCL maintainers. Take it for what it is worth.
An approach that takes Oleg's concerns into account would be to use version number ranges, rather than just a particular version number. Essentially, you are stating "I have tested with everything from version X to version Y". You can also leave the high end open ended if you trust your downstream dependencies not to break you with later versions :-). Oleg Craig
