groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <>
Subject In shape for a 2.4.4 release?
Date Tue, 19 May 2015 19:36:52 GMT
 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
- 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?


View raw message