+1 It’s clear I’ve become a bottleneck in this regard and would love to see others pick up release management duties.
I have markdown document somewhere (likely on an old laptop backup somewhere) I’ll dig it up, update it and share it. I imagine most committers know what the lead up to a release is like — essentially just gather consensus that it’s time to release and figure out what to include.. A high level view of the Storm-specific process of actually creating a release is: 1. Run `mvn release:prepare` followed `mvn release:perform` on the branch to be released. You will need to have an account on repository.apache.org <http://repository.apache.org/> to do this. I believe all committers have access, but I would have to verify that. This will create all the artifacts that will eventually be available in maven central. This step may seem simple, but a lot can go wrong (mainly flaky tests). 2. Once you get a successful maven release, a “staging repository” will be created in the “open” state, meaning it is still writable. You will need to close it, making it read-only and the artifiacts now “staged”. 3. Run `mvn package` for `storm-dist/binary` and `storm-dist/source` to create the actual distributions. 4. Sign and generate checksums for the *.tar.gz and *.zip distribution files. 5. Create a directory in the dist svn repo for the release candidate: https://dist.apache.org/repos/dist/dev/storm/apache-storm-x.x.x-rcx <https://dist.apache.org/repos/dist/dev/storm/apache-storm-x.x.x-rcx> 6. Run `release_notes.py` for the release version, piping the output to RELEASE_NOTES.html. Move that file to the svn release directory, sign it, and generate checksums. 6. Move release files from Step 4 and 6 to the svn directory from Step 5. Add and commit the files. This makes them available in the apache staging repo. — at this point the release candidate is created and staged — 7. Start the VOTE thread. — Assuming successful VOTE — 8. `svn mv https://dist.apache.org/repos/dist/dev/storm/apache-storm-x.x.x-rcx <https://dist.apache.org/repos/dist/dev/storm/apache-storm-x.x.x-rcx> https://dist.apache.org/repos/release/dev/storm/apache-storm-x.x.x` <https://dist.apache.org/repos/release/dev/storm/apache-storm-x.x.x%60>. This will make the release artifacts available on dist.apache.org <http://dist.apache.org/> and the artifacts will start replicating to mirrors. 9. Wait at least 24 hrs. for the mirrors to catch up. 10. Compose blog post announcement. Generate documentation, generate site, and `git push` to publish the site. 11. Announce to [email protected] <mailto:[email protected]>, [email protected] <mailto:[email protected]>, and [email protected] <mailto:[email protected]>. You will need to use your @apache.org email to do this. 12. Tweet, promote, celebrate. ;) I know I’ve glossed over a lot of details. I would suggest someone volunteer to be a RM “guinea pig” and try to do a mock release. We can debug and document the details. Obviously RCs can be cancelled and rolled back, so it would be a harmless exercise. -Taylor > On May 30, 2019, at 5:18 PM, Stig Rohde Døssing <[email protected]> > wrote: > > Hi everyone, > > I think we should have more people willing to act as release managers. > Taylor has expressed a desire to step back from the role (or at least to > not be the only RM), and it would be good if we could have a few people > ready to step up and wear the RM hat. If you're interested in this role, > this thread would be a good place to say so. > > There's some general information about releasing under Apache at > http://www.apache.org/dev/release-publishing.html. > > As I understand it, a new RM will need to at least generate and publish > their signature before they can act as RM. More info at > http://www.apache.org/dev/release-signing.html. I'm not sure whether > linking with the Apache web of trust is also mandatory. > > Taylor, it would be helpful if you could explain any additional steps > beyond what is in the Apache guide to what a release manager needs to do to > release Storm.
