On 11/6/15 10:18 AM, sebb wrote: > 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.]
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-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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
