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 22:22:09 GMT
Don't mean to be terse, just lack of time.

On 11/1/06, Henri Yandell <flamefew@gmail.com> wrote:
> On 11/1/06, Oleg Kalnichevski <olegk@apache.org> wrote:
<snip/>
> >
> > 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).
>
<snap/>

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

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

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.

-Rahul


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