On 6 November 2015 at 16:17, Phil Steitz <phil.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org