On Fri, 6 Nov 2015 12:21:46 -0700, Phil Steitz wrote:
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.
I got it now. Thanks.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
