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. A lot of people (as Martin pointed out) bump the major version because they've added a lot to the API - but we've not done that that often and I'm tempted to think we should mandate that that doesn't happen.
Why is it necessary to mandate such a thing? -- Martin Cooper
> 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. Yeah. Basically we'll do what Java does - charge on with new things and keep the old ones hanging on. Seems like Lang 3.0 could be JDK 1.5 only and not need any package renaming, as long as it maintained the backwards compatibilty. > 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? Solving jar hell isn't that hard. You do internal releases, you pester projects to do a release, or you just don't upgrade. Runtime bugs from jar hell are more of a worry for me. People who have built against a version of Project A that needs Commons B-1.0, and then they put it into production/testing with Commons B-2.0 and not B-1.0. The other side is going to the the new jar hell. Trying to deploy a war file and make sure you have all the necessary transitive dependencies of Commons. Unless we also include the version number in the artifact-id; Maven's going to become painful I think. 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. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
