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.

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
>>
>>> This is a concept people are already familiar with.
>>
>> ---------------------------------------------------------------------
>> 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

Reply via email to