On Sun, 8 Nov 2015 00:45:38 +0000, sebb wrote:
So is the idea to change both the Maven artifact ID and package name
for the beta releases?
i.e. the stable releases would use
Maven AID: commons-math4
package: org.apache.commons.math4
and beta releases:
Maven AID: commons-math4-beta{n}
package: org.apache.commons.math4.beta{n}
Have I got this right?
I think so.
If so, there should be no possibility of jar hell.
It was the purpose, since any solution that could allow JAR hell
has been vetoed.
==
However, to test with the beta code will require the user to modify
their source code to use the new package names.
[And of course fix the source for any API breakages.]
It would be nice if the package rename could be avoided.
This would allow JAR hell.
It might be worth checking how the Maven classifier affects the
classpath.
I suspect that Maven will not consider versions of artifacts whose
classifer does not match, so there won't be any danger of math4-beta1
being used instead of math4 unless the user specifically asks for
beta1.
There might be interesting to be able to use codes in "betaX" and code
in "betaY" at the same time.
Actually that would allow to have releases with different levels of
advancement in different areas of the library.
Assuming monolithic progress is the current situation, where refactored
code cannot be released because other areas are lagging behind.
There could still be a classpath issue if the application has another
jar that depends on Commons Math4 and that does not use the
classifier.
There would then be two incompatible copies of Math4 on the
classpath.
Given that the beta releases should only be used by the adventurous,
this might be a risk worth taking to simply the testing.
JAR hell risk? This has been repelled.
Which procedures would need simplification?
Gilles
On 7 November 2015 at 21:25, Phil Steitz <phil.ste...@gmail.com>
wrote:
On 11/7/15 2:15 PM, Phil Steitz wrote:
On 11/7/15 12:58 PM, James Carman wrote:
As long as the maven coordinates follow suit, go for it. The
community will
let us know if it is a pain in the ass. Also, no need to worry
about
even/odd with this approach
I think its better to use the even/odd approach with this package
naming trick to stay legal within even-numbered lines so we can
then
keep cutting stable odd-numbered (e.g. 3.x) releases and we can
agree that when and even line (e.g. 4) stabilizes we can move to
the
next odd number (5) and set expectation that releases in that line
(5.x) will be stable. Then, e.g. 6. becomes a unstable API line,
etc. Otherwise you end up with sequences like 4.beta1, 4.beta2,
4,
4.1, .... 5.beta1, etc, with no idea when the API has stabilized
(most importantly what releases are going to get
backward-compatible
patch releases with bug-fixes). If we adopt the even/odd
convention
both for [math] developers and users, we can then set the clear
expectation that it's OK to break compat all we like within
even-numbered (effectively beta) lines but once we cut an
odd-numbered release we are going to keep that API stable until the
next odd release.
Sorry, strike that. I think I kind of missed James' point above.
As long as once you drop the .beta in a line you keep the API
stable, I guess it would be OK to dispense with the even/odd. So
basically, we are just saying cut betas until the API stabilizes and
only commit to patch releases for releases without the .beta in the
package / release name. I would be OK with that.
Phil
Phil
On Sat, Nov 7, 2015 at 12:29 PM Gilles
<gil...@harfang.homelinux.org> wrote:
On Sat, 7 Nov 2015 16:52:21 +0100, Emmanuel Bourg wrote:
A roughly equivalent alternative would be to release beta
artifacts
until the API stabilizes and use a different base package and
different
Maven coordinates for each iteration.
For example, commons-math 4.0-beta1 is released with the
org.apache.commons:commons-math4-beta1 coordinates and the
classes
living in the org.apache.commons.math4.beta1 package. Once we
are
happy
with the state of the API we release
org.apache.commons:commons-math4
with the org.apache.commons.math4 base package and we stop
breaking
the
binary compatibility.
With this scheme, binary compatibility is in effect never broken
since
the top-level package is different in each codebase:
org.apache.commons.math4.beta1
org.apache.commons.math4.beta2
etc.
In my opinion the "beta" qualifier better conveys the unstable
nature
of the API than an arbitrary convention like "the whole 4.x line
is
unstable".
"math4.beta1" would be fine too (although "math4u0" was a little
shorter).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
