commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Version mgt idea
Date Fri, 06 Nov 2015 17:24:34 GMT
On 11/6/15 10:18 AM, sebb wrote:
> On 6 November 2015 at 16:17, 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 - 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
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message