groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: In shape for a 2.4.4 release?
Date Wed, 20 May 2015 09:26:22 GMT
Another issue I remembered this morning: the artifactory plugin for
TeamCity that we use is responsible for creating a release branch and
tagging. It is also the one that updates the repository and changes the
version numbers automatically. It is going to be a problem because to do
this it requires credentials on the Git repo. Is this something that we can
ask to infra? Currently we use an authentication key, but user/password is
also supported. Of course we could cheat and use our personal credentials,
but ehm, if we can avoid this...

2015-05-19 23:36 GMT+02:00 Emmanuel Lécharny <elecharny@gmail.com>:

> Le 19/05/15 21:36, Cédric Champeau a écrit :
> >  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
>
> So far, it's up to the PMC to decide who will be the RM, but OTOH, it
> can be anyone. There is no obligation for the ASF to nominate an
> official Release Manager, nor that he/she has to be part of the PMC.
> > - 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
> Usually, when we cut a release, it goes into a staging area, so if it's
> not voted, it can be removed. Is that an option ?
>
> > - Sources/distributions need to be copied manually from Bintray to [1] by
> > the release manager (attn mentors: how?)
>
> scp + commit. The dist are is managed with subversion.
>
>
> > - 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.
>
> I do use my own little script to do that when I cut a release. It's
> dirty, it does the job.
>
> > - release manager announces on dev@ and voting starts
> in fact, the vote *is* an annoucement.
> > - if vote is positive, release manager asks IPMC to vote
>
> That's fine. The inner vote is quite informal (ie, no 72h, etc)
> > - if vote is positive, release manager triggers Maven Central
> > synchronization from Bintray and announces the release on the MLs
> That has to be the last step (ie, teh announcement). Because 200 mirrors
> have to be updated, and all of them might not be updated every hour,
> just be sure to wait 24h before any announcement.
> > - if vote is positive, website needs to be updated too [2]
> Yes, and that should be done when the packages have been moved, and 24h
> before the announcement.
> >
> > 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?
>
>
> sounds good to me
>
>
>

Mime
View raw message