commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Sun, 19 Dec 2004 23:25:22 GMT
From: "Daniel Florey" <>
> So the collections way to handle this issue if to move all classes to a 
> new
subpackage and leave the old ones where they've been before.
To be honest: Is this not very close to my proposal?

Certainly, there is some similarity. Were I to change the semantics of a 
class/method (deliberately), to such a degree that it was backwards 
incompatible, I would have to create a new class/method with a different 

In collections 3, it so happened that I used a new package, but that was 
because the GOAL of the release in many ways was to break up a monolith into 
smaller easier to understand packages. ie. the packages didn't result from 
semantic changes, but they did enable them - the package restructure came 

Other projects will vary, beanutils/logging/betwixt/digester are all 
thinking of incompatible v2s, and I can't comment on them. Another package 
may be the appropriate solution for a particular commons component, however 
a blanket rule doesn't work for me, nor does including the version number. 
If you create a package it should describe its purpose.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message