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.
> Which procedures would need simplification?
As already mentioned, testing with beta{n} involves changing the
package references 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, 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.
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
