On 10/30/06, Sandy McArthur <[EMAIL PROTECTED]> wrote:
On 10/30/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 10/30/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> > From: Sandy McArthur <[EMAIL PROTECTED]>
> > > 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/[EMAIL
PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
