commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: 'End of Life' policy in Jakarta; was Re: [VOTE] JCL dependency versions
Date Wed, 01 Nov 2006 22:22:09 GMT
Don't mean to be terse, just lack of time.

On 11/1/06, Henri Yandell <> wrote:
> On 11/1/06, Oleg Kalnichevski <> wrote:
> >
> > 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).

Call it something else. Invitation to upgrade / preferred version is
x.y.*, some such prodding.

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

Oversimplified view. Some amount of tenacity from users implied there
(also important to note that "fixing it yourself" is not acceptable
for use in many environments).

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

To me, that doesn't paint a good picture of us if we release Commons
Foo with 1.1 and Commons Bar with 1.0.2 some time after that. Which is
the ongoing vote, full circle.


> Hen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message