You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by Dale LaBossiere <dl...@apache.org> on 2018/01/03 17:25:58 UTC
reproducible release process
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
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Geee ... creating a testsuite for a maven plugin that has an effect on deployment is ... le's say: Challenging __
But now I think the plugin should have the necessary test-coverage we need :-)
So right now I would treat this task as "TACKLED".
Chris
Am 01.02.18, 11:03 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi all,
digging myself out of my PLC4X duties for a little while __
I did take this issue to the Maven users list and there were several suggestions:
1) Don't use the test-jar and copy the resources from a relative path outside the module
2) Live with the test-jars
3) Create a new maven plugin to strip the test-jars out
I did think about option 3 but never mentioned it before as it's challenging to have a maven plugin be part of the build it's used in (Maven absolutely doesn't like this). But I have to agree with Roberts opinion on the list, that this is the cleanest option.
1) Has the drawback of pointing to parts outside a module itself. I have always regretted relying on resources outside a Module whenever I used that. This sort of solution always had the habit of biting you when you at least suspect it.
2) Well we discussed that and it was the overall opinion that we don't want that.
So I implemented a maven plugin to strip out the test-jars and added that in the utils directory but didn't include it in the main reactor. The pom also references the apache-parent directly and is completely separate from the rest of the Edgent build. I also gave it a separate groupId (org.apache.edgent.plugins) and a version number 1.0.0. We would have to release that once as a 1.0.0 and probably never have to touch that again. We would have to do that before the next release as we are not able to release as long as we reference SNAPSHOT versions at all.
I manually deployed the SNAPSHOT of the plugin so you should be fine with building without building the plugin yourself. I also wouldn't suggest setting up a CI job for the plugin itself as this will probably never change.
With this solution the test-jar artifacts are installed in the maven local repo but are never deployed to any remote repo.
Would this option be ok?
Chris
Am 28.01.18, 17:58 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Dale,
I took the question over to the maven users list. Hopefully they'll come up with a different solution. Still not that comfortable with the deletion (manual or not).
Also I bumped the Apache parent version, as a new version was released a few days ago. Feel free to merge the pull request (just starting to get used to that workflow)
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Dale LaBossiere <dm...@gmail.com>
Sent: Tuesday, January 23, 2018 4:11:32 PM
To: dev@edgent.apache.org
Subject: Re: reproducible release process
Hi Chris,
Regarding EDGENT-440 and the numerous undesired staged artifacts,
When you manually deleted some staged artifacts (presumably via the browser UI?), did you also have to update the metadata files or such?
A while ago you mentioned creating a script/tool to automate this cleanup (in preference to trying to do more pom/config wacking). What were your thoughts on that? Any pointers, etc?
Thanks,
— Dale
> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
>
>
> Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
digging myself out of my PLC4X duties for a little while __
I did take this issue to the Maven users list and there were several suggestions:
1) Don't use the test-jar and copy the resources from a relative path outside the module
2) Live with the test-jars
3) Create a new maven plugin to strip the test-jars out
I did think about option 3 but never mentioned it before as it's challenging to have a maven plugin be part of the build it's used in (Maven absolutely doesn't like this). But I have to agree with Roberts opinion on the list, that this is the cleanest option.
1) Has the drawback of pointing to parts outside a module itself. I have always regretted relying on resources outside a Module whenever I used that. This sort of solution always had the habit of biting you when you at least suspect it.
2) Well we discussed that and it was the overall opinion that we don't want that.
So I implemented a maven plugin to strip out the test-jars and added that in the utils directory but didn't include it in the main reactor. The pom also references the apache-parent directly and is completely separate from the rest of the Edgent build. I also gave it a separate groupId (org.apache.edgent.plugins) and a version number 1.0.0. We would have to release that once as a 1.0.0 and probably never have to touch that again. We would have to do that before the next release as we are not able to release as long as we reference SNAPSHOT versions at all.
I manually deployed the SNAPSHOT of the plugin so you should be fine with building without building the plugin yourself. I also wouldn't suggest setting up a CI job for the plugin itself as this will probably never change.
With this solution the test-jar artifacts are installed in the maven local repo but are never deployed to any remote repo.
Would this option be ok?
Chris
Am 28.01.18, 17:58 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Dale,
I took the question over to the maven users list. Hopefully they'll come up with a different solution. Still not that comfortable with the deletion (manual or not).
Also I bumped the Apache parent version, as a new version was released a few days ago. Feel free to merge the pull request (just starting to get used to that workflow)
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Dale LaBossiere <dm...@gmail.com>
Sent: Tuesday, January 23, 2018 4:11:32 PM
To: dev@edgent.apache.org
Subject: Re: reproducible release process
Hi Chris,
Regarding EDGENT-440 and the numerous undesired staged artifacts,
When you manually deleted some staged artifacts (presumably via the browser UI?), did you also have to update the metadata files or such?
A while ago you mentioned creating a script/tool to automate this cleanup (in preference to trying to do more pom/config wacking). What were your thoughts on that? Any pointers, etc?
Thanks,
— Dale
> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
>
>
> Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
I took the question over to the maven users list. Hopefully they'll come up with a different solution. Still not that comfortable with the deletion (manual or not).
Also I bumped the Apache parent version, as a new version was released a few days ago. Feel free to merge the pull request (just starting to get used to that workflow)
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Dale LaBossiere <dm...@gmail.com>
Sent: Tuesday, January 23, 2018 4:11:32 PM
To: dev@edgent.apache.org
Subject: Re: reproducible release process
Hi Chris,
Regarding EDGENT-440 and the numerous undesired staged artifacts,
When you manually deleted some staged artifacts (presumably via the browser UI?), did you also have to update the metadata files or such?
A while ago you mentioned creating a script/tool to automate this cleanup (in preference to trying to do more pom/config wacking). What were your thoughts on that? Any pointers, etc?
Thanks,
— Dale
> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
>
>
> Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
>
Re: reproducible release process
Posted by Dale LaBossiere <dm...@gmail.com>.
Hi Chris,
Regarding EDGENT-440 and the numerous undesired staged artifacts,
When you manually deleted some staged artifacts (presumably via the browser UI?), did you also have to update the metadata files or such?
A while ago you mentioned creating a script/tool to automate this cleanup (in preference to trying to do more pom/config wacking). What were your thoughts on that? Any pointers, etc?
Thanks,
— Dale
> On Jan 16, 2018, at 12:53 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> Sorry für the late response.
> Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
>
>
> Von: Dale LaBossiere
> Gesendet: Mittwoch, 10. Januar, 19:50
> Betreff: Re: reproducible release process
> An: dev@edgent.apache.org
>
>
> Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
Sorry für the late response.
Yes you are correct. Naveen doesn't provide any means for the merging. I did use the simple commands you did without any fast forward. Don't know if Apache's git would have accepted that anyway.
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
Von: Dale LaBossiere
Gesendet: Mittwoch, 10. Januar, 19:50
Betreff: Re: reproducible release process
An: dev@edgent.apache.org
Now that release:perform worked… Assuming the RC vote passes and the nexus staging repository is “closed”... It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations. What were the exact cmds you used to merge the release to master, to create: commit 1832130 Merge tag ‘edgent-1.2.0’ git checkout master git pull # ensure master is up to date git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not? — Dale
Re: reproducible release process
Posted by Dale LaBossiere <dm...@gmail.com>.
Now that release:perform worked…
Assuming the RC vote passes and the nexus staging repository is “closed”...
It looks like the maven-release-plugin doesn’t provide any merging of the release to appropriate locations.
What were the exact cmds you used to merge the release to master, to create:
commit 1832130 Merge tag ‘edgent-1.2.0’
git checkout master
git pull # ensure master is up to date
git merge edgent-1.2.0 -m “Merge tag 'edgent-1.2.0’” # did you use —ff-only? should we / not?
— Dale
Re: reproducible release process
Posted by Dale LaBossiere <dm...@gmail.com>.
I added another entry for apache.snapshots.https and changed both to have my pw in the clear… and it worked!
Hmm.
> On Jan 9, 2018, at 6:48 PM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Aaaaahhh … I just noticed that I have a duplicate definition of the repos (in our pom and in the apache root).
> I needed that in order to have the repo urls in the generated maven site, but the ids should match.
> But in my case I have no credentials for “apache-release” or “apache-snapshot”. So probably the root definitions are used.
>
> Chris
>
> Am 10.01.18, 00:26 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
> Hi Dale,
>
> well the id should be apache.releases.https for a release version and apache.snapshots.https for snapshots. The apache-release is just the name of a profile in the apache root pom. I don’t have my password encrypted though, but otherwise my setup is the same.
>
> Chris
>
> Am 09.01.18, 23:41 schrieb "Dale LaBossiere" <dm...@gmail.com>:
>
> when I run the mvn release:perform, it fails when trying to upload to nexus:
>
> Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project edgent-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.edgent:edgent-parent:pom:9.9.0 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/edgent/edgent-parent/9.9.0/edgent-parent-9.9.0.pom. Return code is: 401
>
> I tried added a server decl to my .m2/settings.xml but it didn’t help. I was guessing at the server id based on the repository id “apache-release” in the pom. I also tried an id of “apache.releases.https” but that didn’t help. I can log into https://repository.apache.org with that id/pw.
> <server>
> <id>apache-release</id>
> <username>dlaboss</username> <!— my apache userid —>
> <password>my-encrypted-password</password> <!— my apache pw —>
> </server>
>
> What’s the correct thing to do?
>
> FYI I'm updating releasing.adoc as I go so no need for you to do that.
>
> Thanks,
> — Dale
>
>> On Jan 4, 2018, at 2:25 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>>
>> Hi Dale,
>>
>> that’s unfortunate that you had that many problems … I have to admit that the branch operation directly pushes was new to me … the prepare operation shouldn’t and the perform should only checkout. BUT I do know that for all the data in the scm management block of the pom is important. So, you should have forked, updated the scm information to your fork and then executed the operations.
>>
>> Regarding the questions, the plugin asks:
>> “new working copy version” refers to the version all poms will have after the release.
>>
>> The main duties of the release:branch and release:prepare is to update the version information. In all cases will the originating branch’s version be updated to the new working copy version. Branch will create a branch without updating any version information and prepare will update all versions to the release version (without SNAPSHOT) and tag that in git before updating it again to the “new working copy version”.
>>
>> I thought these versions were self-explanatory, maybe I should elaborate a little more on these.
>>
>> Chris
>>
>>
>> Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dm...@gmail.com>:
>>
>> 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 <ch...@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" <dl...@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
>>>
>>
>>
>>
>
>
>
>
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Aaaaahhh … I just noticed that I have a duplicate definition of the repos (in our pom and in the apache root).
I needed that in order to have the repo urls in the generated maven site, but the ids should match.
But in my case I have no credentials for “apache-release” or “apache-snapshot”. So probably the root definitions are used.
Chris
Am 10.01.18, 00:26 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Dale,
well the id should be apache.releases.https for a release version and apache.snapshots.https for snapshots. The apache-release is just the name of a profile in the apache root pom. I don’t have my password encrypted though, but otherwise my setup is the same.
Chris
Am 09.01.18, 23:41 schrieb "Dale LaBossiere" <dm...@gmail.com>:
when I run the mvn release:perform, it fails when trying to upload to nexus:
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project edgent-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.edgent:edgent-parent:pom:9.9.0 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/edgent/edgent-parent/9.9.0/edgent-parent-9.9.0.pom. Return code is: 401
I tried added a server decl to my .m2/settings.xml but it didn’t help. I was guessing at the server id based on the repository id “apache-release” in the pom. I also tried an id of “apache.releases.https” but that didn’t help. I can log into https://repository.apache.org with that id/pw.
<server>
<id>apache-release</id>
<username>dlaboss</username> <!— my apache userid —>
<password>my-encrypted-password</password> <!— my apache pw —>
</server>
What’s the correct thing to do?
FYI I'm updating releasing.adoc as I go so no need for you to do that.
Thanks,
— Dale
> On Jan 4, 2018, at 2:25 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> that’s unfortunate that you had that many problems … I have to admit that the branch operation directly pushes was new to me … the prepare operation shouldn’t and the perform should only checkout. BUT I do know that for all the data in the scm management block of the pom is important. So, you should have forked, updated the scm information to your fork and then executed the operations.
>
> Regarding the questions, the plugin asks:
> “new working copy version” refers to the version all poms will have after the release.
>
> The main duties of the release:branch and release:prepare is to update the version information. In all cases will the originating branch’s version be updated to the new working copy version. Branch will create a branch without updating any version information and prepare will update all versions to the release version (without SNAPSHOT) and tag that in git before updating it again to the “new working copy version”.
>
> I thought these versions were self-explanatory, maybe I should elaborate a little more on these.
>
> Chris
>
>
> Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dm...@gmail.com>:
>
> 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 <ch...@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" <dl...@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
>>
>
>
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
well the id should be apache.releases.https for a release version and apache.snapshots.https for snapshots. The apache-release is just the name of a profile in the apache root pom. I don’t have my password encrypted though, but otherwise my setup is the same.
Chris
Am 09.01.18, 23:41 schrieb "Dale LaBossiere" <dm...@gmail.com>:
when I run the mvn release:perform, it fails when trying to upload to nexus:
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project edgent-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.edgent:edgent-parent:pom:9.9.0 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/edgent/edgent-parent/9.9.0/edgent-parent-9.9.0.pom. Return code is: 401
I tried added a server decl to my .m2/settings.xml but it didn’t help. I was guessing at the server id based on the repository id “apache-release” in the pom. I also tried an id of “apache.releases.https” but that didn’t help. I can log into https://repository.apache.org with that id/pw.
<server>
<id>apache-release</id>
<username>dlaboss</username> <!— my apache userid —>
<password>my-encrypted-password</password> <!— my apache pw —>
</server>
What’s the correct thing to do?
FYI I'm updating releasing.adoc as I go so no need for you to do that.
Thanks,
— Dale
> On Jan 4, 2018, at 2:25 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> that’s unfortunate that you had that many problems … I have to admit that the branch operation directly pushes was new to me … the prepare operation shouldn’t and the perform should only checkout. BUT I do know that for all the data in the scm management block of the pom is important. So, you should have forked, updated the scm information to your fork and then executed the operations.
>
> Regarding the questions, the plugin asks:
> “new working copy version” refers to the version all poms will have after the release.
>
> The main duties of the release:branch and release:prepare is to update the version information. In all cases will the originating branch’s version be updated to the new working copy version. Branch will create a branch without updating any version information and prepare will update all versions to the release version (without SNAPSHOT) and tag that in git before updating it again to the “new working copy version”.
>
> I thought these versions were self-explanatory, maybe I should elaborate a little more on these.
>
> Chris
>
>
> Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dm...@gmail.com>:
>
> 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 <ch...@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" <dl...@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
>>
>
>
>
Re: reproducible release process
Posted by Dale LaBossiere <dm...@gmail.com>.
when I run the mvn release:perform, it fails when trying to upload to nexus:
Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project edgent-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.edgent:edgent-parent:pom:9.9.0 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): Failed to transfer file: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/edgent/edgent-parent/9.9.0/edgent-parent-9.9.0.pom. Return code is: 401
I tried added a server decl to my .m2/settings.xml but it didn’t help. I was guessing at the server id based on the repository id “apache-release” in the pom. I also tried an id of “apache.releases.https” but that didn’t help. I can log into https://repository.apache.org with that id/pw.
<server>
<id>apache-release</id>
<username>dlaboss</username> <!— my apache userid —>
<password>my-encrypted-password</password> <!— my apache pw —>
</server>
What’s the correct thing to do?
FYI I'm updating releasing.adoc as I go so no need for you to do that.
Thanks,
— Dale
> On Jan 4, 2018, at 2:25 AM, Christofer Dutz <ch...@c-ware.de> wrote:
>
> Hi Dale,
>
> that’s unfortunate that you had that many problems … I have to admit that the branch operation directly pushes was new to me … the prepare operation shouldn’t and the perform should only checkout. BUT I do know that for all the data in the scm management block of the pom is important. So, you should have forked, updated the scm information to your fork and then executed the operations.
>
> Regarding the questions, the plugin asks:
> “new working copy version” refers to the version all poms will have after the release.
>
> The main duties of the release:branch and release:prepare is to update the version information. In all cases will the originating branch’s version be updated to the new working copy version. Branch will create a branch without updating any version information and prepare will update all versions to the release version (without SNAPSHOT) and tag that in git before updating it again to the “new working copy version”.
>
> I thought these versions were self-explanatory, maybe I should elaborate a little more on these.
>
> Chris
>
>
> Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dm...@gmail.com>:
>
> 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 <ch...@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" <dl...@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
>>
>
>
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Dale,
that’s unfortunate that you had that many problems … I have to admit that the branch operation directly pushes was new to me … the prepare operation shouldn’t and the perform should only checkout. BUT I do know that for all the data in the scm management block of the pom is important. So, you should have forked, updated the scm information to your fork and then executed the operations.
Regarding the questions, the plugin asks:
“new working copy version” refers to the version all poms will have after the release.
The main duties of the release:branch and release:prepare is to update the version information. In all cases will the originating branch’s version be updated to the new working copy version. Branch will create a branch without updating any version information and prepare will update all versions to the release version (without SNAPSHOT) and tag that in git before updating it again to the “new working copy version”.
I thought these versions were self-explanatory, maybe I should elaborate a little more on these.
Chris
Am 03.01.18, 23:06 schrieb "Dale LaBossiere" <dm...@gmail.com>:
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 <ch...@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" <dl...@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
>
Re: reproducible release process
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@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" <dl...@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
>
Re: reproducible release process
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dl...@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