commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: AW: AW: AW: [proposal] avoiding jar version nightmares
Date Sun, 19 Dec 2004 23:25:22 GMT
From: "Daniel Florey" <daniel.florey@web.de>
> 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 
name.

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

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.

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