The Maven sources.jar will have the same version as the other Maven artifacts - the sources zip referred to here is the source release tarball/zipfile that is the only actual official Apache release artifact - https://dist.apache.org/repos/dist/release/jclouds/1.9.0/, e.g.
A. On Tue, May 19, 2015 at 12:59 PM, Keegan Witt <[email protected]> wrote: > If they require -incubating in the filename, does that mean it'll be in > the Maven coordinates as well? If so, that's unfortunate since there are > many tools (like IntelliJ) that probably won't be able to automatically > locate the source jar. > > -Keegan > > On Tue, May 19, 2015 at 3:36 PM, Cédric Champeau <[email protected]> > wrote: > >> Hi guys, >> >> I wanted to check with you what is preventing us from releasing 2.4.4. >> Apart from the usual bugfixes, I think the necessary work on the source >> code itself to match the Apache guidance has been done (in particular >> licenses checks). >> >> From my perspective it should be possible to release using the "old >> process" with subtle differences: >> >> - a release manager chosen from the IPMC will initiate the release >> - release will be done from the CI server >> - binaries/sources/distributions will be signed automatically, as usual, >> through Bintray >> - Maven artifacts will be published automatically on Artifactory (OJO) >> >> So far, nothing differs from the usual process but: >> >> - Maven Central synchronization *will* be disabled, instead of done >> automatically until now, so that we can cancel the release if it is >> downvoted >> - Sources/distributions need to be copied manually from Bintray to [1] by >> the release manager (attn mentors: how?) >> - since we do not generate MD5 files through Gradle yet (it's not a >> technical problem), the release manager should generate the checksums for >> sources/distributions/binaries and upload them to [1] too. An open question >> is whether those signatures should be generated in Bintray, in which case >> we need support from them, or from our side, in which case we have to >> update the build to generate them and make them artifacts. >> - release manager announces on dev@ and voting starts >> - if vote is positive, release manager asks IPMC to vote >> - if vote is positive, release manager triggers Maven Central >> synchronization from Bintray and announces the release on the MLs >> - if vote is positive, website needs to be updated too [2] >> >> We have chosen to use a version number *without* -incubating for the >> artifacts. Only the sources zip will have -incubating in the file name, as >> the incubator policy mandates. The website download logic will have to be >> adapted for this special case. >> >> What do you think? >> >> [1] https://dist.apache.org/repos/dist/release/incubator/groovy >> [2] https://github.com/groovy/groovy-website >> >> >
