On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg <ebo...@apache.org> wrote: > Le 10/10/2013 13:26, Ate Douma a écrit : > >> Thoughts? > > A solution could be to change the package for every preview release. > Something like: > > org.apache.commons.experimental.<componentname><number> > > So, for CSV we could release a 0.8 and 0.9 version under the packages: > > org.apache.commons.experimental.csv8 > org.apache.commons.experimental.csv9 > > The package translation could probably be automated by the shade plugin, > such that we keep developing with the org.apache.commons.csv package. > > Emmanuel Bourg
I call this "Extreme Versioning", and I've thought about it in the past. Each release lives in it's own package, major, minor, maintenance. As a developer, this leads you to make a conscious choice as to when to pick up a bug fix or new feature from a new version of a jar, you have to act. This is different than just new dropping jars into your classpath (or POM) and hoping for the best. It also guarantees binary compatibility, BC becomes a non-issue. It is an extreme POV to be sure. If I want to create an "unsupported" jar combo, I have to shade jars and change package names. Gary > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
