commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [PROPOSAL] Major versions require package name change
Date Mon, 30 Oct 2006 17:53:19 GMT
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"


> Occasional drastic pruning of code is needed to keep it healthy and
> manageable. But we should not be eager to run out and break
> compatibility without deliberate and compelling reasons.

I agree that we should not run out and break compatibility without deliberate and compelling
reasons. In fact, I'd suggest that one of the beneficial side-effects of adopting this as
a policy would be that we would all be more reticent about making those incompatible changes,
leading to more minor and compatible releases - which I would argue is a Good Thing.

I'll admit its less fun though. Is that what the negative viewpoint here is? Or is it just
that the negatives have never faced jar hell?

At the moment, I haven't heard any debate of the validity of the problem, or alternatives
to the solution/

Stephen





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