You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2015/11/06 17:17:18 UTC
[math] Version mgt idea
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 - so 4.0 and 4.1
might not be compatible. We would always maintain both an odd and
even branch - ideally in such a way that when an even numbered line
stabilized it would add a last hurrah of breaks and move to odd.
People wanting stable APIs could just stick with the odd-numbered
lines and [math] developers wanting to experiment with things and
not worry about compatibility could do that in the even-numbered
lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
I know above violates Commons policy if we actually cut releases
from the even-numbered branches - we would have to get agreement
from the Commons PMC that this is OK or somehow label the releases
differently. Just an idea to get us out of our current bind...
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Peter Ansell <an...@gmail.com>.
On 7 November 2015 at 03:17, Phil Steitz <ph...@gmail.com> 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 - so 4.0 and 4.1
> might not be compatible. We would always maintain both an odd and
> even branch - ideally in such a way that when an even numbered line
> stabilized it would add a last hurrah of breaks and move to odd.
> People wanting stable APIs could just stick with the odd-numbered
> lines and [math] developers wanting to experiment with things and
> not worry about compatibility could do that in the even-numbered
> lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
>
> I know above violates Commons policy if we actually cut releases
> from the even-numbered branches - we would have to get agreement
> from the Commons PMC that this is OK or somehow label the releases
> differently. Just an idea to get us out of our current bind...
>
Other alternatives may be to make extensive use of "milestone" builds
to allow Maven Central releases using -M2,-M3/etc., while making it
clear to people who are familiar with that schema that the build is
unstable, or to use .FINAL in the Spring fashion and use .BETA etc.
before that.
If the API is constantly in flux for that long, then it doesn't need a
full version series, IMO, as people could just be experimenting with
.BETA or -M releases to test.
At some point it isn't our fault if users do not understand these
well-known suffixes as indicating a lack of strict backwards or
forwards compatibility.
Cheers,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Nov 6, 2015 at 11:17 AM Phil Steitz <ph...@gmail.com> 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 - so 4.0 and 4.1
> might not be compatible. We would always maintain both an odd and
> even branch - ideally in such a way that when an even numbered line
> stabilized it would add a last hurrah of breaks and move to odd.
> People wanting stable APIs could just stick with the odd-numbered
> lines and [math] developers wanting to experiment with things and
> not worry about compatibility could do that in the even-numbered
> lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
>
> I know above violates Commons policy if we actually cut releases
> from the even-numbered branches - we would have to get agreement
> from the Commons PMC that this is OK or somehow label the releases
> differently. Just an idea to get us out of our current bind...
>
>
I'm -1 on this idea. I don't like the idea of causing compatibility breaks
within a major revision, no matter what. We should follow semantic
versioning guidelines wrt compatibility breaks. If not, you're going to
run into trouble in places like OSGi, which assumes you're following those
rules.
Re: [math] Version mgt idea
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 06/11/2015 18:18, sebb a écrit :
> On 6 November 2015 at 16:17, Phil Steitz <ph...@gmail.com> 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 - so 4.0 and 4.1
>> might not be compatible. We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently. Just an idea to get us out of our current bind...
>
> That would likely cause problems with Maven, which will pick the
> latest release, regardless of whether it is even or odd.
No because we change the artifact coordinates too.
So people who depend on apache.commons.math3 will never see
artifacts from the apache.commons.math4 series.
> [However changing the gid/uid without changing the package name also
> causes problems with Maven.]
>
> Unless it is possible to add a marker to the release such that Maven
> does not consider it when looking for the latest release.
> The only such marker I know of is SNAPSHOT - such releases are not
> added to Maven Central so cannot be accidentally added to the
> classpath.
>
> Maybe there is another marker which could be used that tells Maven not
> to consider that version.
>
> If there is no other such marker, one way to avoid these issues would
> be to not publish the even releases to Maven Central.
> Users would have to download them some other way.
>
> Maybe there is mileage in having a staging repo for Commons as a half-way house.
> Users would need to specifically add the repo to their pom to use the repo.
> [I think I suggested something like this for some Commons Maven
> plugins that were for developer use only]
>
> Note that publishing even-numbered releases to the ASF mirror service
> can also cause problems if the unstable releases are not clearly
> marked.
>
>> Phil
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
On 11/6/15 10:18 AM, sebb wrote:
> On 6 November 2015 at 16:17, Phil Steitz <ph...@gmail.com> 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 - so 4.0 and 4.1
>> might not be compatible. We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently. Just an idea to get us out of our current bind...
> That would likely cause problems with Maven, which will pick the
> latest release, regardless of whether it is even or odd.
> [However changing the gid/uid without changing the package name also
> causes problems with Maven.]
I am curious how many people actually use unversioned dependencies.
I would never do that. But I get the concern that as soon as you
release an even-numbered release it becomes the latest release and
people might just grab it.
>
> Unless it is possible to add a marker to the release such that Maven
> does not consider it when looking for the latest release.
> The only such marker I know of is SNAPSHOT - such releases are not
> added to Maven Central so cannot be accidentally added to the
> classpath.
>
> Maybe there is another marker which could be used that tells Maven not
> to consider that version.
>
> If there is no other such marker, one way to avoid these issues would
> be to not publish the even releases to Maven Central.
> Users would have to download them some other way.
>
> Maybe there is mileage in having a staging repo for Commons as a half-way house.
> Users would need to specifically add the repo to their pom to use the repo.
> [I think I suggested something like this for some Commons Maven
> plugins that were for developer use only]
>
> Note that publishing even-numbered releases to the ASF mirror service
> can also cause problems if the unstable releases are not clearly
> marked.
Right - there we could mark them. We could make it clear in release
notes, READMEs, web pages, etc.
Phil
>
>> Phil
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by sebb <se...@gmail.com>.
On 6 November 2015 at 16:17, Phil Steitz <ph...@gmail.com> 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 - so 4.0 and 4.1
> might not be compatible. We would always maintain both an odd and
> even branch - ideally in such a way that when an even numbered line
> stabilized it would add a last hurrah of breaks and move to odd.
> People wanting stable APIs could just stick with the odd-numbered
> lines and [math] developers wanting to experiment with things and
> not worry about compatibility could do that in the even-numbered
> lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
>
> I know above violates Commons policy if we actually cut releases
> from the even-numbered branches - we would have to get agreement
> from the Commons PMC that this is OK or somehow label the releases
> differently. Just an idea to get us out of our current bind...
That would likely cause problems with Maven, which will pick the
latest release, regardless of whether it is even or odd.
[However changing the gid/uid without changing the package name also
causes problems with Maven.]
Unless it is possible to add a marker to the release such that Maven
does not consider it when looking for the latest release.
The only such marker I know of is SNAPSHOT - such releases are not
added to Maven Central so cannot be accidentally added to the
classpath.
Maybe there is another marker which could be used that tells Maven not
to consider that version.
If there is no other such marker, one way to avoid these issues would
be to not publish the even releases to Maven Central.
Users would have to download them some other way.
Maybe there is mileage in having a staging repo for Commons as a half-way house.
Users would need to specifically add the repo to their pom to use the repo.
[I think I suggested something like this for some Commons Maven
plugins that were for developer use only]
Note that publishing even-numbered releases to the ASF mirror service
can also cause problems if the unstable releases are not clearly
marked.
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 06/11/2015 18:31, Gilles a écrit :
> Hi.
>
> 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 -
>
> I like the proposal to be more lax on compatibility breaking than
> I ever dreamed of. ;-)
Yeah, good idea!
Go for it.
>
>> so 4.0 and 4.1
>> might not be compatible.
>
> Isn't that going to cause JAR hell?
As long as people are aware there are no compliance implied,
then they know what they have to do when they decide to
use this.
best regards,
Luc
>
> Gilles
>
>> We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines. In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently. Just an idea to get us out of our current bind...
>>
>> Phil
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Ole Ersoy <ol...@gmail.com>.
On 11/13/2015 08:12 AM, Gilles wrote:
> 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.
You could be right. Personally, I'm fine doing:
`git clone ...`
`mvn install`
`get to work..`
I'm assuming the critical feedback is being targeted at the more complex components that are hard to find in the wild, so testers have a natural impetus to jump through a few hoops.
>
> 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.
True. I'm assuming that someone needing a feature will first google, find out that what they are looking for is available - and is potentially better in the beta version - so they will be ok with building and experimenting with the branch 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... :-}
The complexity of multiple interdependent features being refactored simultaneously might also turn some off. If multiple beta branches are created isolating each change it could make it easier to request and process feedback.
Cheers,
- Ole
>
> 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 <ph...@gmail.com> wrote:
>>>
>>>> On 11/6/15 4:46 PM, Gary Gregory wrote:
>>>>> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <ph...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <ph...@gmail.com>
>> wrote:
>>
>>> On 11/6/15 4:46 PM, Gary Gregory wrote:
>>>> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz
>>>> <ph...@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
Re: [math] Version mgt idea
Posted by Ole Ersoy <ol...@gmail.com>.
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?
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).
Cheers,
- Ole
On 11/06/2015 06:51 PM, Gary Gregory wrote:
> On Fri, Nov 6, 2015 at 4:02 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 11/6/15 4:46 PM, Gary Gregory wrote:
>>> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <ph...@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
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 8 Nov 2015 14:29:31 +0000, sebb wrote:
> On 8 November 2015 at 13:50, Gilles <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by sebb <se...@gmail.com>.
On 8 November 2015 at 13:50, Gilles <gi...@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 <ph...@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 <gi...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
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.
Which procedures would need simplification?
Gilles
> On 7 November 2015 at 21:25, Phil Steitz <ph...@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
>>>> <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by sebb <se...@gmail.com>.
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?
If so, there should be no possibility of jar hell.
==
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.
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 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.
On 7 November 2015 at 21:25, Phil Steitz <ph...@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 <gi...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
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 <gi...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
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 <gi...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by James Carman <ja...@carmanconsulting.com>.
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
On Sat, Nov 7, 2015 at 12:29 PM Gilles <gi...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
On 11/7/15 10:29 AM, Gilles 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).
+1 for this idea - gets around the compat breaks within
normal-looking major version releases and conveys the right idea in
the package name. Also sets clear enough expectation that you are
not going to get bug fixes is 4.beta1 without going to 4.beta2 (so
bug fixes may come along with compat breaks).
Phil
>
> Regards,
> Gilles
>
>> This is a concept people are already familiar with.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Emmanuel Bourg <eb...@apache.org>.
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.
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". This is a concept people are already familiar with.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 6, 2015 at 4:02 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 11/6/15 4:46 PM, Gary Gregory wrote:
> > On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <ph...@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
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 6 Nov 2015 16:53:00 -0800, Gary Gregory wrote:
> On Fri, Nov 6, 2015 at 4:42 PM, Gilles <gi...@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
>>>> <ph...@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
Re: [math] Version mgt idea
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 6, 2015 at 4:42 PM, Gilles <gi...@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 <ph...@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?
Gary
>
> Gilles
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <ph...@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).
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
On 11/6/15 4:46 PM, Gary Gregory wrote:
> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <ph...@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.
Phil
>
> Gary
>
>
>> Phil
>>> Gary
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <ph...@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.
Breaking BC without a package and coord change is a no-go. 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.
Gary
>
> Phil
> >
> > Gary
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
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.
Phil
>
> Gary
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gary Gregory <ga...@gmail.com>.
>
> 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.
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.
Gary
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 6 Nov 2015 12:21:46 -0700, Phil Steitz wrote:
> On 11/6/15 11:02 AM, Gilles wrote:
>> On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote:
>>> On 11/6/15 10:31 AM, Gilles wrote:
>>>> Hi.
>>>>
>>>> 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 -
>>>>
>>>> I like the proposal to be more lax on compatibility breaking than
>>>> I ever dreamed of. ;-)
>>>>
>>>>> so 4.0 and 4.1
>>>>> might not be compatible.
>>>>
>>>> Isn't that going to cause JAR hell?
>>>
>>> Yes, within the even-numbered branches. But we would repackage and
>>> rename at each version cut as we do now.
>>
>> I don't follow.
>> Is top-level package renaming in order: e.g.
>> "org.apache.commons.math4m0" for 4.0
>> "org.apache.commons.math4m1" for 4.1
>> ?
>
> Sorry, I was not clear. I meant that we would do the repackaging
> only at major release, so both above would be .math4
>
>
>>
>> This would be akin to the "experimental" package idea evoked
>> in an earlier incarnation of this discussion.
>>
>>> So the only "hell" would
>>> be if someone deploys multiple different versions from an
>>> even-numbered branch. We would expect them to be less widely
>>> deployed, so this would be less of an issue.
>>
>> I don't follow either.
>> What issue did you intend to solve with the proposal?
>
> Basically, limit the compat breaks to lines "known" to contain
> breaks.
>>
>> My wish is that all (users and developers) can enjoy a timely
>> official release of the "bleeding edge"; whereas it now seems
>> to me that you are only talking about branch naming.
>> [And even-numbered ones will likely not be released because
>> of JAR hell.]
>
> That is what I was trying to support. RERO with constant API change
> means you have to release API breaks often. That's the crux of our
> problem with 4.0 now. If we want it to have a stable API, we need
> to finish stabilizing it before we release anything; otherwise we
> need to follow immediately with 5, 6 etc. What I was suggesting is
> that we could just advertise the fact that the 4.x API is not
> expected to be stable. Once it stabilizes, it will become 5.x.
> This has the advantage that users wanting a stable API know what to
> use and we only have to support 2 lines at any given time.
I got it now. Thanks.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
On 11/6/15 11:02 AM, Gilles wrote:
> On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote:
>> On 11/6/15 10:31 AM, Gilles wrote:
>>> Hi.
>>>
>>> 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 -
>>>
>>> I like the proposal to be more lax on compatibility breaking than
>>> I ever dreamed of. ;-)
>>>
>>>> so 4.0 and 4.1
>>>> might not be compatible.
>>>
>>> Isn't that going to cause JAR hell?
>>
>> Yes, within the even-numbered branches. But we would repackage and
>> rename at each version cut as we do now.
>
> I don't follow.
> Is top-level package renaming in order: e.g.
> "org.apache.commons.math4m0" for 4.0
> "org.apache.commons.math4m1" for 4.1
> ?
Sorry, I was not clear. I meant that we would do the repackaging
only at major release, so both above would be .math4
>
> This would be akin to the "experimental" package idea evoked
> in an earlier incarnation of this discussion.
>
>> So the only "hell" would
>> be if someone deploys multiple different versions from an
>> even-numbered branch. We would expect them to be less widely
>> deployed, so this would be less of an issue.
>
> I don't follow either.
> What issue did you intend to solve with the proposal?
Basically, limit the compat breaks to lines "known" to contain breaks.
>
> My wish is that all (users and developers) can enjoy a timely
> official release of the "bleeding edge"; whereas it now seems
> to me that you are only talking about branch naming.
> [And even-numbered ones will likely not be released because
> of JAR hell.]
That is what I was trying to support. RERO with constant API change
means you have to release API breaks often. That's the crux of our
problem with 4.0 now. If we want it to have a stable API, we need
to finish stabilizing it before we release anything; otherwise we
need to follow immediately with 5, 6 etc. What I was suggesting is
that we could just advertise the fact that the 4.x API is not
expected to be stable. Once it stabilizes, it will become 5.x.
This has the advantage that users wanting a stable API know what to
use and we only have to support 2 lines at any given time.
Phil
>
> Or what did I miss?
>
> Gilles
>
>>
>> Phil
>>>
>>> Gilles
>>>
>>>> We would always maintain both an odd and
>>>> even branch - ideally in such a way that when an even numbered
>>>> line
>>>> stabilized it would add a last hurrah of breaks and move to odd.
>>>> People wanting stable APIs could just stick with the odd-numbered
>>>> lines and [math] developers wanting to experiment with things and
>>>> not worry about compatibility could do that in the even-numbered
>>>> lines. In effect, this is sort of what we are doing now in 3.x /
>>>> 4.x.
>>>>
>>>> I know above violates Commons policy if we actually cut releases
>>>> from the even-numbered branches - we would have to get agreement
>>>> from the Commons PMC that this is OK or somehow label the releases
>>>> differently. Just an idea to get us out of our current bind...
>>>>
>>>> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 6 Nov 2015 10:36:51 -0700, Phil Steitz wrote:
> On 11/6/15 10:31 AM, Gilles wrote:
>> Hi.
>>
>> 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 -
>>
>> I like the proposal to be more lax on compatibility breaking than
>> I ever dreamed of. ;-)
>>
>>> so 4.0 and 4.1
>>> might not be compatible.
>>
>> Isn't that going to cause JAR hell?
>
> Yes, within the even-numbered branches. But we would repackage and
> rename at each version cut as we do now.
I don't follow.
Is top-level package renaming in order: e.g.
"org.apache.commons.math4m0" for 4.0
"org.apache.commons.math4m1" for 4.1
?
This would be akin to the "experimental" package idea evoked
in an earlier incarnation of this discussion.
> So the only "hell" would
> be if someone deploys multiple different versions from an
> even-numbered branch. We would expect them to be less widely
> deployed, so this would be less of an issue.
I don't follow either.
What issue did you intend to solve with the proposal?
My wish is that all (users and developers) can enjoy a timely
official release of the "bleeding edge"; whereas it now seems
to me that you are only talking about branch naming.
[And even-numbered ones will likely not be released because
of JAR hell.]
Or what did I miss?
Gilles
>
> Phil
>>
>> Gilles
>>
>>> We would always maintain both an odd and
>>> even branch - ideally in such a way that when an even numbered line
>>> stabilized it would add a last hurrah of breaks and move to odd.
>>> People wanting stable APIs could just stick with the odd-numbered
>>> lines and [math] developers wanting to experiment with things and
>>> not worry about compatibility could do that in the even-numbered
>>> lines. In effect, this is sort of what we are doing now in 3.x /
>>> 4.x.
>>>
>>> I know above violates Commons policy if we actually cut releases
>>> from the even-numbered branches - we would have to get agreement
>>> from the Commons PMC that this is OK or somehow label the releases
>>> differently. Just an idea to get us out of our current bind...
>>>
>>> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Phil Steitz <ph...@gmail.com>.
On 11/6/15 10:31 AM, Gilles wrote:
> Hi.
>
> 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 -
>
> I like the proposal to be more lax on compatibility breaking than
> I ever dreamed of. ;-)
>
>> so 4.0 and 4.1
>> might not be compatible.
>
> Isn't that going to cause JAR hell?
Yes, within the even-numbered branches. But we would repackage and
rename at each version cut as we do now. So the only "hell" would
be if someone deploys multiple different versions from an
even-numbered branch. We would expect them to be less widely
deployed, so this would be less of an issue.
Phil
>
> Gilles
>
>> We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines. In effect, this is sort of what we are doing now in 3.x /
>> 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently. Just an idea to get us out of our current bind...
>>
>> Phil
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Version mgt idea
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
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 -
I like the proposal to be more lax on compatibility breaking than
I ever dreamed of. ;-)
> so 4.0 and 4.1
> might not be compatible.
Isn't that going to cause JAR hell?
Gilles
> We would always maintain both an odd and
> even branch - ideally in such a way that when an even numbered line
> stabilized it would add a last hurrah of breaks and move to odd.
> People wanting stable APIs could just stick with the odd-numbered
> lines and [math] developers wanting to experiment with things and
> not worry about compatibility could do that in the even-numbered
> lines. In effect, this is sort of what we are doing now in 3.x /
> 4.x.
>
> I know above violates Commons policy if we actually cut releases
> from the even-numbered branches - we would have to get agreement
> from the Commons PMC that this is OK or somehow label the releases
> differently. Just an idea to get us out of our current bind...
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org