commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [math] Version mgt idea
Date Sat, 07 Nov 2015 01:42:04 GMT
On Fri, 6 Nov 2015 16:53:00 -0800, Gary Gregory wrote:
> On Fri, Nov 6, 2015 at 4:42 PM, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>
>> On Fri, 6 Nov 2015 17:02:01 -0700, Phil Steitz wrote:
>>
>>> On 11/6/15 4:46 PM, Gary Gregory wrote:
>>>
>>>> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz 
>>>> <phil.steitz@gmail.com>
>>>> wrote:
>>>>
>>>> On 11/6/15 2:51 PM, Gary Gregory wrote:
>>>>>
>>>>>> 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 -
>>>>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>> This sounds awfully complicated for my puny human
brain.
>>>>>>
>>>>> How, exactly?  Seems pretty simple to me.  The even-numbered 
>>>>> release
>>>>> lines may have compat breaks; but the odd-numbered do not.
>>>>>
>>>>>> It's bad enough that I have to remember how each FOSS project 
>>>>>> treats
>>>>>> versions numbers, but having an exception within a Commons 
>>>>>> component is
>>>>>> even worse. This is a non-starter for me.
>>>>>>
>>>>> Do you have any better suggestions?  The problem we are trying to
>>>>> solve is we can't RERO while sticking to the normal compat rules
>>>>> without turning major versions all the time, which forces users 
>>>>> to
>>>>> repackage all the time and us to support more versions 
>>>>> concurrently
>>>>> than we have bandwidth to do.
>>>>>
>>>>> I do not see how a different version scheme will determine how 
>>>>> many
>>>> branches the community supports.
>>>>
>>>
>>> If we just keep one 4.x branch that keeps cutting (possibly
>>> incompatible) releases, that is just one line, one branch.  If we
>>> have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any
>>> compat breaks, we end up having to maintain and release 4.0.1,
>>> 5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand
>>> the 4, 5 users in terms of bug fixes as we move on to 6.
>>>
>>>>
>>>> Breaking BC without a package and coord change is a no-go.
>>>>
>>>
>>> We have done this before and we will probably do it again - and 
>>> more
>>> if we have to don't separate out an unstable line.
>>>
>>>>  You have to
>>>> think about this jar as a dependency that can be deeply nested in 
>>>> a
>>>> software stack. Commons components are such creatures. I 
>>>> unfortunately
>>>> run
>>>> into this more than I'd like: Big FOSS project A depends on B 
>>>> which
>>>> depends
>>>> on C. Then I want to integrate with Project X which depends on Y 
>>>> which
>>>> depends on different versions of B and C. Welcome to jar hell if B 
>>>> and C
>>>> are not compatible. If B and C follow the rule of break-BC -> new
>>>> package/coords, then all is well.
>>>>
>>>
>>> The mitigation here is that we would not expect the even-numbered
>>> releases to be deployed widely.
>>>
>>
>> Or we can prevent any potential JAR hell by changing the top-level
>> package name for every release in the unstable series:
>>
>> 4.0 -> org.apache.commons.math4u0
>> 4.1 -> org.apache.commons.math4u1
>>
>> This would also offer the possibility to write a code using
>> classes from several unstable releases (e.g. to compare their
>> performance).
>
>
> Pardon my daftness, but if you change package/coord names, what are 
> you
> gaining compared to the usual major version changes?
>

Objectively, nothing...
But IIUC Phil's paragraph, above, using a dual numbering would
highlight the "unstable" nature of some releases: the whole 4.x
series would be known (in advance) to be unstable, while if we
release a usual 4.0, some user might assume it to be "stable",
only to see it abandoned a few months later when 5.0 is released.
Moreover, at each major number bump, we'd have to advertize (in
words) whether that release is stable or not, while with the dual
numbering the warning would be carried by number in the package
name.

Maybe it's only a psychological trick.  But if it can help to
release more often, it would have led to a real improvement! :)

Gilles



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message