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 <[email protected]>: > 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 > > >
