edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dlab...@apache.org>
Subject reproducible release process
Date Wed, 03 Jan 2018 17:25:58 GMT
Hi Chris, 

At a high level, we need to ensure someone can reproduce what you just went through for 1.2.0.

It feels like I should try going through the process for a, fictitious at the moment, 1.3.0
release.  i.e., going all the way up to staging the release in dist.apache.org and in Nexus
(“Closing the staging repository”), then cleaning that all up like it never happened (“Actions
if the vote failed”, plus removing the release/1.3 branch).  Does that make sense?  

As long as I don’t “git push” the created branch and pom-version-change commits, is
cleanup as easy as just destroying my repo-clone?

Looking at src/site/asciidoc/releasing.adoc, it looks pretty complete, but...

In the vote-passed case, where’s the step / cmds to merge the release to master?

In the vote-failed case, presumably the “fixes” are make on the release branch, and the
eventual “Prepare” redo with the same args does what’s needed.  But where’s the step
/ (cherrypick?) cmds to get the fixes to the develop branch? (imagine there are numerous commits
for the fixes)

I’m also unclear on the flow for a bug fix release like 1.2.1.  Just make the changes on
the release/1.2 branch and BEGIN the process with “mvn release:prepare … -tag edgent-1.2.1
-DdevelopmentVersion=1.2.2-SNAPSHOT -DreleaseVersion=1.2.1”?  And again steps / (cherrypick?)
cmds to get the 1.2.1 fixes to the develop branch.

Once I can get through this I’ll update the RM-guide.  At least initially I’ll leave releasing.adoc
as is (covering what it covers) and just update the RM-guide accordingly and link to it. 
I don’t want to duplicate info and I don’t want to merge it into a single doc — unless
you agree that migrating releasing.adoc content to the wiki (and removing releasing.adoc)
is OK :-) 

— Dale
View raw message