edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale LaBossiere <dml.apa...@gmail.com>
Subject Re: reproducible release process
Date Wed, 03 Jan 2018 22:06:36 GMT
Hmm… 

per the releasing.adoc, I ran the release:branch step in a new clone of the GitHub mirror
repo (I neglected to clone the ASF repo) and it actually auto-pushed 3 items to the ASF repo
:-(    (when release:branch completed, there were still two commits pending/not-yet-pushed
as expected) 

I also neglected to “git checkout develop” so these auto-pushed commits were to the master
branch (though they netted to a no-op change) :-(

Lastly even after cleaning up (below) release/9.9 is still showing up in the Branch pulldown
of on the GitHub repo :-(  Filed https://issues.apache.org/jira/browse/INFRA-15777 <https://issues.apache.org/jira/browse/INFRA-15777>

When I tried again with a fresh ASF repo clone and on the develop branch, release:branch is
prompting and I’m not sure what to reply with - don’t understand what the “new working
copy version” terminology is really identifying.  Did you run with more -D options?   I’m
guessing it’s asking about what to advance the develop branch version to (for the next release),
and when you were doing the 1.2.0 release I’m guessing that you must have replied/specified
1.3.0-SNAPSHOT?

@Dales-MacBook-Pro:604> git status
On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working tree clean
@Dales-MacBook-Pro:605> mvn release:branch -P platform-android,platform-java7,distribution
-DbranchName=release/9.9 -DautoVersionSubmodules=true
…
What is the new working copy version for "Apache Edgent"? (org.apache.edgent:edgent-parent)
1.3.1-SNAPSHOT: :   



FYI, from my first botched release:branch run:

These 3 auto-pushed changes were now on master:
	- commit of pom.xml on master (yikes) to change the scm-tag from edgent-1.2.0 => release/9.9
	- created the release/9.9 branch
	- commit of pom.xml on master to undo the prior commit (scm-tag back to edgent-1.2.0)

To cleanup I:
	- deleted the release/9.9 branch locally and in the asf repo
		Sadly, asf repo’s GitHub mirror still shows “release/9.9” in its branch pulldown.
	- “git reset —hard HEAD^^” followed by a “git push —force” to essentially remove
the above two commits on master


> On Jan 3, 2018, at 2:20 PM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
> 
> Hi Dale,
> 
> I think I did write down all the steps involving Maven in the document:
> 
> src/site/asciidoc/releasing.adoc
> 
> The merge with the other RM doc is that the release-perform will create the source tar/zip
we vote on in “target/checkout/target/***.tar.gz” and the corresponding zip. The files
should follow the exact naming convention used to deploy it on the staging svn.
> 
> In the last release, I manually created the directory structure and checked in the files.
After that I used the existing scripts to deploy the voted-on release to prod.
> 
> But it’s always good for others to try it too … and yes … it will do all the steps
without pushing (it will however create a Maven staging repo). The staging repo is simply
removed by a simple click and with the git repo, a simple forced git reset should do the trick.
> 
> If you run into any problems, I’ll try to help as soon as possible.
> 
> Chris
> 
> 
> 
> 
> 
> 
> Am 03.01.18, 18:26 schrieb "Dale LaBossiere" <dlaboss@apache.org>:
> 
>    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
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message