commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
Date Wed, 01 Nov 2006 21:19:58 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.

I don't think the end of life concept fits for us - nothing gets end
of life'd unless we lose the files, close the project or have to
retract the release for some reason (legal).

So..Alexandria could be argued as being end of life...just about.
mod_jserv is pretty much end of life. Lang 1.0 is not end of life - if
someone asks a question about it we're not going to then not answer it
- even if our answer is "that was fixed in 1.1". If someone has a
definite need for something on an old version and can't upgrade; and
someone here has the itch; then it'll get fixed otherwise we'd
probably point out how they can fix it themselves (svn etc) and help
if they find problems in the build etc.

So I don't think the JCL people would be end of lifeing things in the
below. Unless we just view end of life as everything but the active
release(s) [where Collections has a 2.x and 3.x set, but the rest of
us just have the one active release].

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

A supported dependency range would have value if it existed, but I
think it'll be too hard to maintain/test-for/support you'd need
something gump like with a bit more added to it. The current situation
seems to be a much better return on time - if a project depends on JCL
1.1, then the math of version numbers recommends that you don't try to
put JCL 1.0.x in it. If a project depends on JCL 1.0.2, then you
should feel 90% safe to try out JCL 1.0.4 instead.

Hen

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