Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of flamefew@gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Xv7lBmrq1lQR8vm2kBKsn0Pinqi3Drrfy815YpGG6TIju/a5UaCF7iEGsHiUUHT57ZCTgIRCIX/Oykl+ZicF9TxtR/MXvMg6U/7E55ZfGPgGQ/91Sl00TjlPymZoO+mks0SJglDrhhNCRw8WbtnrFQUQ7hA4puEJwtpzBs7wRBs=
Message-ID: <31cc37360610301424s5f382ebbw69c7fe147d08764f@mail.gmail.com>
Date: Mon, 30 Oct 2006 14:24:14 -0800
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [PROPOSAL] Major versions require package name change
In-Reply-To: <6bde122b0610301415j7d0501f1i61d17daf736b5af0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061030175319.24351.qmail@web86511.mail.ird.yahoo.com>
	 <31cc37360610301332x1a467031rc4fb09a35bae5182@mail.gmail.com>
	 <6bde122b0610301415j7d0501f1i61d17daf736b5af0@mail.gmail.com>

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