On Sun, 8 Nov 2015 14:29:31 +0000, sebb wrote:
On 8 November 2015 at 13:50, Gilles <gil...@harfang.homelinux.org>
wrote:
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.
And it would still be avoided for people that don't use the beta{n}
jar classifier.
IIUC, Gary wrote that he would not accept the any possibility of
JAR hell due to Commons released components.
Which procedures would need simplification?
As already mentioned, testing with beta{n} involves changing the
package references
In code?
Do you meant that
s/math4.beta1/math4.beta2/
is a problem?
as well as changing the code to fix any API breaks.
The latter is unavoidable; the former is potentially avoidable.
Since the beta jars are only for use by Beta testers,
I wouldn't reduce it to that.
As I explained above, keeping the same package name would prevent
the most interesting use-cases (cf. previous post).
I also am not sure what you assume that beta-testers should be
able to do.
We also want "beta-testers" to be able to indicate that they prefer
feature "X" as implemented in "beta1" even as it may have been
refactored in "beta2".
it seemed to me
that it might be worth reducing the work that they have to do.
But the convenience (simplification) would carry the risk of jar
clashes.
It seemed to me that a beta tester should be able to cope with this
risk.
In the case I exposed above, this would not be a risk, it would
be a certainty IIUC. Hence I'd not favour keeping the same name.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
