On 11/6/15 11:02 AM, Gilles wrote: > On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote: >> On 11/6/15 10:31 AM, Gilles wrote: >>> Hi. >>> >>> On Fri, 6 Nov 2015 09:17:18 -0700, Phil Steitz wrote: >>>> Here is an idea that might break our deadlock re backward >>>> compatibility, versioning and RERO: >>>> >>>> Agree that odd numbered versions have stable APIs - basically >>>> adhere >>>> to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0, >>>> 5.1... but even-numbered lines can include breaks - >>> >>> I like the proposal to be more lax on compatibility breaking than >>> I ever dreamed of. ;-) >>> >>>> so 4.0 and 4.1 >>>> might not be compatible. >>> >>> Isn't that going to cause JAR hell? >> >> Yes, within the even-numbered branches. But we would repackage and >> rename at each version cut as we do now. > > I don't follow. > Is top-level package renaming in order: e.g. > "org.apache.commons.math4m0" for 4.0 > "org.apache.commons.math4m1" for 4.1 > ?
Sorry, I was not clear. I meant that we would do the repackaging only at major release, so both above would be .math4 > > This would be akin to the "experimental" package idea evoked > in an earlier incarnation of this discussion. > >> So the only "hell" would >> be if someone deploys multiple different versions from an >> even-numbered branch. We would expect them to be less widely >> deployed, so this would be less of an issue. > > I don't follow either. > What issue did you intend to solve with the proposal? Basically, limit the compat breaks to lines "known" to contain breaks. > > My wish is that all (users and developers) can enjoy a timely > official release of the "bleeding edge"; whereas it now seems > to me that you are only talking about branch naming. > [And even-numbered ones will likely not be released because > of JAR hell.] That is what I was trying to support. RERO with constant API change means you have to release API breaks often. That's the crux of our problem with 4.0 now. If we want it to have a stable API, we need to finish stabilizing it before we release anything; otherwise we need to follow immediately with 5, 6 etc. What I was suggesting is that we could just advertise the fact that the 4.x API is not expected to be stable. Once it stabilizes, it will become 5.x. This has the advantage that users wanting a stable API know what to use and we only have to support 2 lines at any given time. Phil > > Or what did I miss? > > Gilles > >> >> Phil >>> >>> Gilles >>> >>>> We would always maintain both an odd and >>>> even branch - ideally in such a way that when an even numbered >>>> line >>>> stabilized it would add a last hurrah of breaks and move to odd. >>>> People wanting stable APIs could just stick with the odd-numbered >>>> lines and [math] developers wanting to experiment with things and >>>> not worry about compatibility could do that in the even-numbered >>>> lines. In effect, this is sort of what we are doing now in 3.x / >>>> 4.x. >>>> >>>> I know above violates Commons policy if we actually cut releases >>>> from the even-numbered branches - we would have to get agreement >>>> from the Commons PMC that this is OK or somehow label the releases >>>> differently. Just an idea to get us out of our current bind... >>>> >>>> Phil > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
