commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [PROPOSAL] Major versions require package name change
Date Mon, 30 Oct 2006 22:24:14 GMT
On 10/30/06, Sandy McArthur <sandymac@apache.org> wrote:
> On 10/30/06, Henri Yandell <flamefew@gmail.com> wrote:
> > On 10/30/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> > > From: Sandy McArthur <sandymac@apache.org>
> > > > If we want to come up with the notion of a "super" version, something
> > > > that is more broad than a "major" version and includes non-backwards
> > > > compatible changes I'm fine with that.
> > > >
> > > > But mandating that any major release be completely non-backwards
> > > > compatible is silly.
> > >
> > > So what does a major version mean? Surely a major version means "we have changed
the code so it is no longer compatible, you cannot upgrade simlpy and easily"
> >
> > I was thinking the same thing - we define major version as a
> > non-backwards compatible API change.
>
> [...]
>
> > And how do I know which Commons jars to deploy? Let's say I resolve my
> > transitive structure and I've got a list with Commons Lang 3.0, 2.1
> > and 2.0 in it. Which ones do I deploy? All three? Just 3.0 and 2.1?
> > How do I know which ones are package name compatible?
> >
> > Seems that we end up with the Axis way:  Lang2 1.0. Just so people can
> > tell that it's okay to have Lang2 1.0 and Lang 2.1 in the same
> > classpath but not Lang 2.0.
>
> First you suggest that major version numbers be for non-backwards
> compatible releases.
> Then you suggest the major version number should be moved into the
> product name and the major version number resets to 1.
> So what's the point of a major version number if it always 1?

It wouldn't be; the Axis guys are releasing Axis2 1.1 at some point
soon (afaik). They may even have an Axis2 2.0 someday.

This is more a problem with the package rename thing - it's not enough
to be of use. We'll have another world of jar hell if all we do is
change the package name.

> How is that better than point releases, minor releases, major releases
> and then a product name change release? see:
> http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200610.mbox/%3c6bde122b0610301130i59c47281nd5360e007a73ec05@mail.gmail.com%3e

I didn't mean to steal the idea - my focus is on a problem I hadn't
seen with Stephen's proposal until just then rather than the solution.

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