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?
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]
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
