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 <zack.shoy...@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 <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/
