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 23:02:50 GMT
On 11/1/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> 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).

I was surprised to learn that the many of the big serious places don't
use our binaries anyway - they have mandatory rules that they have to
build it from source. I can imagine that smaller places have 'don't
fork internally' rules. Makes sense as the cost of doing so is hard if
you're not organized as a company and large enough for that cost to be
relatively small.

If there is no one interested in a backport etc, fix it yourself is
all you're ever going to get. It's hard to judge that until it happens
- if someone can convince me of the necessity of a backport of Lang
1.0, then I'll do it. Takes tenacity as you said though.

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

I'm definitely on board with you on that one - we should ideally not
release with old versions of Commons dependencies. It means that we,
the Commons community, are not agreeing with the "it's stable" view of
another part of the Commons community. Ideally we should also not be
using any deprecated calls on those libraries.

It gets nice and tricky when you start to compound version numbering:

If Digester releases a new version and the only change is a move from
Collections 2 to Collections 3; does that mean Digester should also do
a major release, or is it a minor or bugfix release. This is about the
time that a single jar release starts to sound attractive (not all of
commons, but all of the ones that would have internal dependencies).

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