On Thu, Apr 7, 2011 at 4:07 AM, sebb <seb...@gmail.com> wrote: > On 7 April 2011 07:35, Henri Yandell <flame...@gmail.com> wrote: >> I've been pondering the tension between stability and innovation. >> >> Once 3.0 is out I'd like to add an alpha subpackage: >> >> org.apache.commons.lang-alpha >> >> It's specifically a location of code that is: >> >> a) Not linked to a version. When we move to 4.0 it does not change. >> b) Does not offer backwards compatibility. Classes move out of >> lang-alpha and into lang3 (or lang4 etc). >> >> Not all new code goes there, but much does. The 'contrib' package of >> an open source project is an essential aspect of allowing the project >> to innovate without burden. If I can convince us to achieve a goal of >> frequent releases, we'll need to be able to release code that we're >> not 100% sure about into our stable packages. It doesn't solve the >> cataclysmic changes (moving to Java 5.0 for example), but it handles a >> lot of items. >> >> I'm not wedded to the alpha name btw; would love to hear of a better one. >> >> A side effect that I like is that people can monitor the changes to >> the alpha package to get a feel for what's coming/what's arrived. > > Sounds like a good idea, but I the code should be released as a > separate jar, otherwise it will cause havoc with binary compatibility.
I think a separate jar would be lot less valuable - that basically makes it a separate project/branch etc. Even if we mess around in Maven to produce multiple jars, we're still create two separate artifacts simply to deal with any tooling for binary compat checking that don't have a filter. Am I missing some element of binary compatibility that would cause havoc; or is this a case where the havoc it will cause is entirely intended? i.e. "Here be dragons" will allow dragons. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
