This is great news!
However I think we need to keep everything in the git repo. "release_scripts"
or something.
________________________________________
From: Ignasi Barrera <n...@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/
