commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
Date Wed, 01 Nov 2006 20:26:44 GMT
On 11/1/06, Oleg Kalnichevski <olegk@apache.org> 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.
>
<snip/>

We may present it differently, but many of us think some "policy" (not
in the totalitarian sense, but in the "has to make sense" sense) is
missing. Be it the package renaming, trying to get components to have
a coherent story for the most common dependecies, or EOL procedures --
I see them as many sides of the same (multifaceted) coin. We cannot
afford to evolve as a bunch of hard-to-predict whimsical bits and
pieces, there has to be an undercurrent.


> 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.
>
<snap/>

I wasn't implying we require JCL 1.1 now, but that when we do, we
diligently upgrade with each new release (for those components that
release). Otherwise we have Foo that needs 1.0.2 and Bar that needs
1.1 and it cannot be obvious to everyone what its implication on
needing Foo and Bar together is.


> Take it for what it is worth.
>
<snip/>

You're modest ;-)

-Rahul


> Oleg
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message