now I see your reasoning 3.3.n were expected to be final quality: they were not, they were dropped (vote result was -1, result sent to trash)
3.5.0-alpha-n is expected to be alpha quality: from tests, we have the alpha quality (IMHO even more quality, but not final quality), then the vote will be positive *for an alpha* and we'll publish the result Regards, Hervé Le dimanche 26 février 2017, 11:44:48 CET Robert Scholte a écrit : > On Sun, 26 Feb 2017 04:58:24 +0100, Manfred Moser > > <[email protected]> wrote: > > Imho it should go to Central just like any other release. All components > > and everything. The version clearly tells thats its alpha and this > > allows for clean testing, embedding and so on. > > > > We have done it in the past and I dont see any reason for changing this. > > Well, Karl Heinz's link only shows those which were deployed, not the ones > which weren't. > Also, we've skipped a lot of versions in the 3.3.x, because we had a > different approach: just make that 3.3.n and simply burn it if there are > issues. We could have called this release 3.5.0, we see some issues and > decide if that should block the release. > > The jansi temp files might be a blocker for me if we are going to publish > this version. > > Robert > > > Manfred > > > > Stephen Connolly wrote on 2017-02-25 16:05: > >> So if I am embedding Maven, how do I embed Maven 3.5.0-alpha-1? > >> > >> (I know it should not be a big issue as we should have the release soon > >> anyway, but more from the principal POV) > >> > >> Consider the Jenkins "evil" job type plugin that has dependencies on > >> some > >> of the artifacts that are in the staging repository? If there is a need > >> to > >> update the adapter libs for that to work with alpha-1, how would that be > >> possible if we don't publish the artifacts at least somewhere? > >> On Sat 25 Feb 2017 at 23:23, Robert Scholte <[email protected]> > >> > >> wrote: > >>> It depends on what the task of Central is. If it for *dependencies*, > >>> there's no need to publish pre-final versions; don't think we should > >>> motive plugins to depend on alphas. > >>> > >>> AFAIK the common way to get a new version of Maven is via > >>> http://maven.apache.org/download.cgi and not via Central. > >>> > >>> This is also about hygiene. Not every artifact belongs in Central > >>> (we've > >>> seen continuous deployment-like releases), and pre-releases could > >>> belong > >>> to that group. > >>> > >>> Funny, just like Jigsaw there's a clear difference between libraries > >>> and > >>> applications; I don't mind treating them differently, especially in > >>> these > >>> unofficial release stages. > >>> > >>> Robert > >>> > >>> On Sat, 25 Feb 2017 22:55:55 +0100, Karl Heinz Marbaise > >>> > >>> <[email protected]> wrote: > >>> > Hi, > >>> > > >>> > based on the started discussion about either to bring 3.5.0-alpha-1 > >>> > >>> to > >>> > >>> > Central or not I would suggest to discuss in a separate thread and > >>> > prevent using the VOTE's threads for that (as Stephen already > >>> > >>> mentioned). > >>> > >>> > Using Central: > >>> > o Everybody can use it and make tests on it. > >>> > > >>> > Using an other repository: > >>> > o Which one? > >>> > > >>> > Using only dist area? Or something different? > >>> > > >>> > WDY? > >>> > >>> > Based on earlier releases which had been in Central with alpha's: > >>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%2 > >>> 0AND%20a%3A%22apache-maven%22>>> > >>> > Kind regards > >>> > Karl Heinz Marbaise > >>> > > >>> > --------------------------------------------------------------------- > >>> > To unsubscribe, e-mail: [email protected] > >>> > For additional commands, e-mail: [email protected] > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> -- > >> > >> Sent from my phone > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
