You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Ignasi Barrera <na...@apache.org> on 2015/03/19 17:28:50 UTC
Automated releases
Hi!
We currently have a release process that is a pain [1], and there are
several open issue that aim to tweak the poms to make the project more
release friendly.
After several releases trying to fix them, I've come to the conclusion
that we don't need to go nuts trying to make the maven-release-plugin
happy. Using that plugin is not a must, an in our case is causing some
trouble:
* Releases can't be automated and there are many (many!) interactive prompts.
* It changes versions in a sub-optimal way: in many places the
"${project.version}" variables are replaced by the version, which is
not convenient.
* It is error-prone, and you have to take care, as it pushes the
changes to the git repository by default.
Being #1 the most important, and in an effort to automate the whole
release process, I've created the "prepare_release.sh" script [2] that
does the same in an automated way. Here is an example invocation:
nacx@maqui:~/src/asf $ ./prepare_release.sh -r 1.9.0 -n 2.0.0-SNAPSHOT
The release process will start with the following properties:
- Current branch: master
- Current SNAPSHOT: 2.0.0-SNAPSHOT
- Release version: 1.9.0
- Next SNAPSHOT: 2.0.0-SNAPSHOT
- Release Candidate version: 1.9.0-rc2
- Repos: jclouds,jclouds-labs,jclouds-labs-openstack,jclouds-labs-aws,jclouds-labs-google,jclouds-karaf,jclouds-cli
Do you want to continue? (y|n)
As you see, you just pass the release version and the next snapshot,
and it will compute all what is needed (including which is the RC
number to use based on the existing RCs).
The script will, in all repos:
* Update the versions to the release version
* Run a build to verify all tests pass.
* Create the tag.
* Update the versions to the next development snapshot.
* Run a new build to verify it also works.
* Deploy release artifacts to the Maven staging repository.
The release process, with this changes will just consist on:
1. Running this script
2. Manually closing the staging repo
3. Manually push the tags
4. Move the artifacts tot he RC svn repo (there is already an script for this).
5. Send the VOTE
If no one is against this, I plan to cut the 1.9.0-rc2 using this
script and update the instructions in the wiki page.
Any feedback on the script is very welcome!
BTW. I also think that the right place for this kind of release
scripts is the SVN and not the "scripts" folder in the jclouds repo.
If we have to change them to accomodate a release, having to check the
changes in the Git repo we're releasing seems unconvenient. So I'd
propose to remove that "scripts" folder and use the SVN as the home
for the release related scripts.
Ignasi
[1] https://cwiki.apache.org/confluence/display/JCLOUDS/Releasing+jclouds
[2] https://dist.apache.org/repos/dist/dev/jclouds/
Re: Automated releases
Posted by Andrew Phillips <ap...@qrmedia.com>.
PS: Does the script try to create a new branch every time, or is that
configurable? E.g. 1.9.1 will obviously *not* need a new branch to be
created.
Regards
ap
Re: COMMERCIAL:Automated releases
Posted by Personal <ch...@gmail.com>.
+1 I think storing this release tooling in SVN is totally fine for now. I suppose an alternative could be a jclouds scripts repo or something similar in git, but that is a bit more work for infra and might be overkill. SVN seems to be a good solution for now.
Thanks for the work on this Ignasi!
Thanks,
Chris
--
Chris Custine
From: Andrew Phillips <ap...@qrmedia.com>
Reply: dev@jclouds.apache.org <de...@jclouds.apache.org>>
Date: March 26, 2015 at 7:54:45 AM
To: dev@jclouds.apache.org <de...@jclouds.apache.org>>
Subject: Re: COMMERCIAL:Automated releases
> Personally, I see more benefits and more convenient to have the
> release scripts in SVN.
Based on what you explained, Ignasi, I tend to agree - especially to
break the "circular dep" between using the release script to generate
the release and having to tweak it.
SVN seems fine for me - I'd then just say that we should include those
things that are already in the "scripts" directory in jclouds/jclouds
there too.
Regards
ap
Re: COMMERCIAL:Automated releases
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Personally, I see more benefits and more convenient to have the
> release scripts in SVN.
Based on what you explained, Ignasi, I tend to agree - especially to
break the "circular dep" between using the release script to generate
the release and having to tweak it.
SVN seems fine for me - I'd then just say that we should include those
things that are already in the "scripts" directory in jclouds/jclouds
there too.
Regards
ap
Re: COMMERCIAL:Automated releases
Posted by Ignasi Barrera <na...@apache.org>.
I would really like to elaborate on this.
As said, I think the jclouds repo is not a good place because the
release script might need changes that one will only detect while
actually performing the release. These changes can only be verified
once the release process finishes, but... If the release is already
made (and the tag created), then the modified script can't be
included. Would the workflow then be to drop the tag and go through
the release process (it takes a considerable amount of time) again? I
think this is not convenient.
Having the script in the main github repo has some benefits:
* The script is in the same place than all the jclouds code.
* Can be easily reviewed in pull requests.
But SVN has also some benefits:
* If the release script is in Github, the script for a release might
not be included in that release tag for the mentioned reasons, but
then,
* If the release scripts are in Github: the scripts themselves are
*not* part of the release, but the "source tarball" (which is the
actual ASF release) will include them. This would required that the
"good and updated" vetsion of the script is there, and one might have
to re-run the release just to include the changes in the release
script.
* The release candidate artifacts must be published to the SVN. It
seems convenient to have already there the release and the
verification scripts. All the release related stuff is in one single
place.
* The scripts can also be versioned and tagged there, if needed.
Personally, I see more benefits and more convenient to have the
release scripts in SVN.
On 19 March 2015 at 19:32, Zack Shoylev <za...@rackspace.com> wrote:
> This is great news!
> However I think we need to keep everything in the git repo. "release_scripts" or something.
> ________________________________________
> From: Ignasi Barrera <na...@apache.org>
> Sent: Thursday, March 19, 2015 11:28 AM
> To: dev@jclouds.apache.org
> Subject: COMMERCIAL:Automated releases
>
> Hi!
>
> We currently have a release process that is a pain [1], and there are
> several open issue that aim to tweak the poms to make the project more
> release friendly.
>
> After several releases trying to fix them, I've come to the conclusion
> that we don't need to go nuts trying to make the maven-release-plugin
> happy. Using that plugin is not a must, an in our case is causing some
> trouble:
>
> * Releases can't be automated and there are many (many!) interactive prompts.
> * It changes versions in a sub-optimal way: in many places the
> "${project.version}" variables are replaced by the version, which is
> not convenient.
> * It is error-prone, and you have to take care, as it pushes the
> changes to the git repository by default.
>
> Being #1 the most important, and in an effort to automate the whole
> release process, I've created the "prepare_release.sh" script [2] that
> does the same in an automated way. Here is an example invocation:
>
> nacx@maqui:~/src/asf $ ./prepare_release.sh -r 1.9.0 -n 2.0.0-SNAPSHOT
> The release process will start with the following properties:
> - Current branch: master
> - Current SNAPSHOT: 2.0.0-SNAPSHOT
> - Release version: 1.9.0
> - Next SNAPSHOT: 2.0.0-SNAPSHOT
> - Release Candidate version: 1.9.0-rc2
> - Repos: jclouds,jclouds-labs,jclouds-labs-openstack,jclouds-labs-aws,jclouds-labs-google,jclouds-karaf,jclouds-cli
> Do you want to continue? (y|n)
>
>
> As you see, you just pass the release version and the next snapshot,
> and it will compute all what is needed (including which is the RC
> number to use based on the existing RCs).
>
> The script will, in all repos:
>
> * Update the versions to the release version
> * Run a build to verify all tests pass.
> * Create the tag.
> * Update the versions to the next development snapshot.
> * Run a new build to verify it also works.
> * Deploy release artifacts to the Maven staging repository.
>
>
> The release process, with this changes will just consist on:
>
> 1. Running this script
> 2. Manually closing the staging repo
> 3. Manually push the tags
> 4. Move the artifacts tot he RC svn repo (there is already an script for this).
> 5. Send the VOTE
>
>
> If no one is against this, I plan to cut the 1.9.0-rc2 using this
> script and update the instructions in the wiki page.
>
> Any feedback on the script is very welcome!
>
>
>
> BTW. I also think that the right place for this kind of release
> scripts is the SVN and not the "scripts" folder in the jclouds repo.
> If we have to change them to accomodate a release, having to check the
> changes in the Git repo we're releasing seems unconvenient. So I'd
> propose to remove that "scripts" folder and use the SVN as the home
> for the release related scripts.
>
>
> Ignasi
>
>
>
> [1] https://cwiki.apache.org/confluence/display/JCLOUDS/Releasing+jclouds
> [2] https://dist.apache.org/repos/dist/dev/jclouds/
Re: COMMERCIAL:Automated releases
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
This is great news!
However I think we need to keep everything in the git repo. "release_scripts" or something.
________________________________________
From: Ignasi Barrera <na...@apache.org>
Sent: Thursday, March 19, 2015 11:28 AM
To: dev@jclouds.apache.org
Subject: COMMERCIAL:Automated releases
Hi!
We currently have a release process that is a pain [1], and there are
several open issue that aim to tweak the poms to make the project more
release friendly.
After several releases trying to fix them, I've come to the conclusion
that we don't need to go nuts trying to make the maven-release-plugin
happy. Using that plugin is not a must, an in our case is causing some
trouble:
* Releases can't be automated and there are many (many!) interactive prompts.
* It changes versions in a sub-optimal way: in many places the
"${project.version}" variables are replaced by the version, which is
not convenient.
* It is error-prone, and you have to take care, as it pushes the
changes to the git repository by default.
Being #1 the most important, and in an effort to automate the whole
release process, I've created the "prepare_release.sh" script [2] that
does the same in an automated way. Here is an example invocation:
nacx@maqui:~/src/asf $ ./prepare_release.sh -r 1.9.0 -n 2.0.0-SNAPSHOT
The release process will start with the following properties:
- Current branch: master
- Current SNAPSHOT: 2.0.0-SNAPSHOT
- Release version: 1.9.0
- Next SNAPSHOT: 2.0.0-SNAPSHOT
- Release Candidate version: 1.9.0-rc2
- Repos: jclouds,jclouds-labs,jclouds-labs-openstack,jclouds-labs-aws,jclouds-labs-google,jclouds-karaf,jclouds-cli
Do you want to continue? (y|n)
As you see, you just pass the release version and the next snapshot,
and it will compute all what is needed (including which is the RC
number to use based on the existing RCs).
The script will, in all repos:
* Update the versions to the release version
* Run a build to verify all tests pass.
* Create the tag.
* Update the versions to the next development snapshot.
* Run a new build to verify it also works.
* Deploy release artifacts to the Maven staging repository.
The release process, with this changes will just consist on:
1. Running this script
2. Manually closing the staging repo
3. Manually push the tags
4. Move the artifacts tot he RC svn repo (there is already an script for this).
5. Send the VOTE
If no one is against this, I plan to cut the 1.9.0-rc2 using this
script and update the instructions in the wiki page.
Any feedback on the script is very welcome!
BTW. I also think that the right place for this kind of release
scripts is the SVN and not the "scripts" folder in the jclouds repo.
If we have to change them to accomodate a release, having to check the
changes in the Git repo we're releasing seems unconvenient. So I'd
propose to remove that "scripts" folder and use the SVN as the home
for the release related scripts.
Ignasi
[1] https://cwiki.apache.org/confluence/display/JCLOUDS/Releasing+jclouds
[2] https://dist.apache.org/repos/dist/dev/jclouds/
Re: Automated releases
Posted by Ignasi Barrera <na...@apache.org>.
Agree with the version thing. I've checked the script many times now and
I'm convinced it won't screw thing up.
Anyway, I intentionally left the tag push as a manual step just to make
sure we can verify each tag before.
El 19/03/2015 17:53, "Ignasi Barrera" <na...@apache.org> escribió:
> Nope. Currently it does not create the corresponding bugfix branches. But
> I'd put that in a separate script, as it is not directly related to the
> release and I would'nt complicate more this one.
> El 19/03/2015 17:48, "Andrew Phillips" <ap...@qrmedia.com> escribió:
>
>> Any feedback on the script is very welcome!
>>>
>>
>> Er...it sounds AWESOME? ;-)
>>
>> Many, many thanks for this, Ignasi - all the releasers owe you at least a
>> beer now. I'm certainly for trying this, we just need to make sure we're a
>> little more diligent about checking things like POM versions in the review
>> process to make sure we catch any issues in the script early.
>>
>> Thanks!
>>
>> ap
>>
>
Re: Automated releases
Posted by Ignasi Barrera <na...@apache.org>.
Nope. Currently it does not create the corresponding bugfix branches. But
I'd put that in a separate script, as it is not directly related to the
release and I would'nt complicate more this one.
El 19/03/2015 17:48, "Andrew Phillips" <ap...@qrmedia.com> escribió:
> Any feedback on the script is very welcome!
>>
>
> Er...it sounds AWESOME? ;-)
>
> Many, many thanks for this, Ignasi - all the releasers owe you at least a
> beer now. I'm certainly for trying this, we just need to make sure we're a
> little more diligent about checking things like POM versions in the review
> process to make sure we catch any issues in the script early.
>
> Thanks!
>
> ap
>
Re: Automated releases
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Any feedback on the script is very welcome!
Er...it sounds AWESOME? ;-)
Many, many thanks for this, Ignasi - all the releasers owe you at
least a beer now. I'm certainly for trying this, we just need to make
sure we're a little more diligent about checking things like POM
versions in the review process to make sure we catch any issues in the
script early.
Thanks!
ap