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 Fri, 13 Nov 2015 14:12:44 GMT
On Mon, 9 Nov 2015 10:34:43 -0600, Ole Ersoy wrote:
> If I'm interested in some functionality that is 'beta' then I first
> have to realize that it's 'beta'...Maybe just tag the branch beta.
> After that there's probably (Judging from the number of people
> communicating here) 1/2 people interested.  Isn't it easier for them
> to just just check out the beta branch and manage the process
> internally using their own internal 'beta' naming convention until
> they are happy with the quality?

[IIUC]
With this approach, I think that we won't get feedback from would-be
testers who don't want to have to "manually" download and compile.

We need to _release_ the beta versions.

Also, for CM developers, what you describe does not seem to add
anything: they already can create branches and experiment locally.

>
> From here it looks like the core problem is that there are two many
> modules intermingled in CM causing friction / weighing down the
> release process for each of the individual modules (Which I'm
> currently imagining).

Could be... :-}

Regards,
Gilles

> Cheers,
> - Ole
>
> On 11/06/2015 06:51 PM, Gary Gregory wrote:
>> On Fri, Nov 6, 2015 at 4:02 PM, Phil Steitz <phil.steitz@gmail.com> 
>> 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.
>>>
>> Respectfully Phil, my point is that while this might be true, it is 
>> in
>> practice irrelevant. We cannot control the spread of our jars and 
>> their
>> usage, hence the importance of BC.
>>
>> Gary
>>
>>> Phil
>>>> Gary
>>>>
>>>>
>>>>> Phil
>>>>>> Gary
>>>>>>
>>>>>


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


Mime
View raw message