release jclouds 1.6.0-rc.1
codefromthecrypt opened this issue · comments
This will be the first release of jclouds 1.6 recommended to integrate with.
Please make sure any of jclouds, jclouds-labs, jclouds-chef, jclouds-karaf, and jclouds-cli are released from their respective 1.6.x branch. cc @iocanel @nacx @gaul
Work to do:
- jclouds
- staging repo closed
- staging repo verified
- staging repo released
- tags pushed
- in maven central
- jclouds-labs
- staging repo closed
- staging repo verified
- staging repo released
- tags pushed
- in maven central
- jclouds-chef
- staging repo closed
- staging repo verified
- staging repo released
- tags pushed
- in maven central
- jclouds-karaf
- staging repo closed
- staging repo verified
- staging repo released
- tags pushed
- in maven central
- jclouds-cli
- staging repo closed
- staging repo verified
- staging repo released
- tags pushed
- in maven central
- communication
- await maven central sync
- email jclouds-dev google group
Here are the release commands for jclouds:
mvn release:clean release:prepare -DreleaseVersion=1.6.0-rc.1 -Dtag=jclouds-1.6.0-rc.1 -DdevelopmentVersion=1.6.0-SNAPSHOT -DpushChanges=false
mvn clean release:perform -DconnectionUrl=scm:git:file://`pwd`/.git -Dtag=jclouds-1.6.0-rc.1 -Dgoals="deploy -DskipTests"
<close oss sonatype staging repository and test it, then release it> https://oss.sonatype.org/index.html#stagingRepositories
git push
git push --tags
jclouds repo for testing: https://oss.sonatype.org/content/repositories/orgjclouds-073
next up: test, then cut labs, chef, karaf, cli
tested with compute-basics on aws-ec2
tested route53, dynect, ultradns with denominator live tests
tested blobstore-basics with cloudfiles-us
released and pushed tags.
next up: cut labs, chef, karaf, cli
I plan to cut labs tomorrow early am PST, so yeah.. last minute changes have <=10hrs :)
commands to cut labs:
mvn release:clean release:prepare -DpomFileName=`pwd`/labs/pom.xml -DreleaseVersion=1.6.0-rc.1 -Dtag=jclouds-labs-1.6.0-rc.1 -DdevelopmentVersion=1.6.0-SNAPSHOT -DpushChanges=false
mvn clean release:perform -DpomFileName=`pwd`/labs/pom.xml -DconnectionUrl=scm:git:file://`pwd`/.git -Dtag=jclouds-labs-1.6.0-rc.1 -Dgoals="deploy -DskipTests"
@sharedocs I could probably use your help. I've tried the above commands to release labs, but it seems to want to publish 1.6.0-SNAPSHOT vs 1.6.0-rc.1. Any ideas?
@adriancole Looking into it. Also looks like the formatting for the checkboxes in this issue has gone a bit weird with the addition of labs?
maybe github it doesn't like the extra work, either ? :)
Thanks for your help.. only thought I had was maybe the parent references
in labs were screwing the release plugin's sense of what version it should
be updating.
jclouds core is in maven central.
edited to add link
ran all integration tests in Denominator against this release. It passes fine.
I'll start filling up a test output directory with api results. This will take a while.
# from 1.6.x branch
cd apis
for I in `ls |egrep -v '(pom.xm|target)'`;do (cd $I;mvn -Plive -o clean install > /Users/adriancole/workspace/git/jclouds.github.com/documentation/releasenotes/1.6.0/`basename $PWD`.txt;cp ./target/surefire-reports/TestSuite.txt /Users/adriancole/workspace/git/jclouds.github.com/documentation/releasenotes/1.6.0/`basename $PWD`-failures.txt);done
only thought I had was maybe the parent references in labs
I suspect the problem is, that unlike the main aggregator which also updates jclouds-project, the labs projects depend on a snapshot version of jclouds-project, which isn't part of the release reactor tree. I wonder what happens if we first change all the jclouds-project references in the labs projects to point to jclouds-project:1.6.0-rc.1.
Also, are you running this from the top level or from jclouds/labs?
Last syntax was run from top level. I tried a different from labs to no
avail. I think we will at least need to set the version of parent, if not
do the 'jclouds.version' game we do in chef and karaf.
I think we will at least need to set the version of parent
By setting the jclouds-project version explicitly to 1.6.0-rc.1 in the labs POMs we should be able to release this - it would mean that jclouds-labs releases of a separate commit, though. We have to keep a snapshot version in the aggregator, though, because otherwise there won't be any snapshots to release ;-)
For future releases we have to somehow separate the jclouds-project version (and the version of all non-labs dependencies, such as the drivers) from the labs project versions. sigh
Since you mention karaf and cli...those are in separate repos. Do you think that would make sense here too?
I'm ok with a separate commit for labs, and understand that means a
different tag
you mean move labs to a separate repo? absolutely, as it helps avoid all
sorts of trouble, and we can always filter-in projects once they graduate,
saving version history.
and understand that means a different tag
I saw that in the release commands ;-) Do you feel like a POM restructure for labs for this release too, or rather get this out and wait for the next RC? I think the "quick fix" for now would be:
- For all modules in labs, change the jclouds-project version to 1.6.0-rc.1 (this also means the org.jclouds deps are automatically at 1.6.0-rc.1)
- Leave only the aggregator version at 1.6.0-SNAPSHOT
- Run the release commands from the labs folder
you mean move labs to a separate repo?
Yes. Once this release is done we can then think about how to restructure. We'd just need to change all the jclouds-project deps back to 1.6.0-SNAPSHOT initially.
I'll let you make the call on quick fix vs not. labs aren't critical to
release immediately unless karaf or cli depends on them.
Let me know how I can be of assistance here since I just restructured
labs/openstack. Thx!
On Sat, Mar 9, 2013 at 8:54 AM, Adrian Cole notifications@github.comwrote:
I'll let you make the call on quick fix vs not. labs aren't critical to
release immediately unless karaf or cli depends on them.—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1399#issuecomment-14666309
.
labs aren't critical to release immediately
OK, then let's have a look at the structure, fix and release soon. No need to rush out a quick fix then.
jclouds-chef repo ready for testing: https://oss.sonatype.org/content/repositories/orgjclouds-106/
Live tested Chef Community and Hosted Chef, and uploaded the results here (will open the PR once the release notes are complete).
All live tests working for Chef Community, two failing in Hosted Chef: one is a checksum comparison and it seems that something has changed in the way they store the cookbook information; will take a look for future releases, as it does not block the common cookbook functionality. The second one is a known issue in Hosted Chef, as the Client index is not properly populated. Once they fix it, the live test will pass.
jclouds-chef repo tested with Chef Community and Hosted Chef. Released and pushed tags.
Once labs is released I'll live test the Abiquo provider.
Hmm...tricky now. After handling the jclouds vs. jclouds-labs version issue, we're now stuck at the following: if we run @adriancole 's suggested
mvn release:clean release:prepare -DpomFileName=labs/pom.xml -DreleaseVersion=1.6.0-rc.1 -Dtag=jclouds-labs-1.6.0-rc.1 -DdevelopmentVersion=1.6.0-SNAPSHOT -DpushChanges=false
we end up with a commit that covers all the POMs:
If we run the release commands from the labs folder (or, equivalently, using -f labs/pom.xml from the root), the plugin doesn't make the release commits because it adds
[INFO] Executing: cmd.exe /X /C "git add -- project\pom.xml virtualbox\pom.xml pom.xml"
but then finds
C:\Users\aphillips\Workspaces\Personal\jclouds\jclouds>git status --porcelain
M labs/pom.xml
M labs/project/pom.xml
M labs/virtualbox/pom.xml
in the repo and refuses to make the commit.
@adriancole Any chance you can create a jclouds-labs repo to see if we can test how easy it would be from there? I suspect that will save us a lot of messing around if we don't mind having the labs code in a different repo...
Sure. In about an hour or less.
On Saturday, March 9, 2013, Andrew Phillips wrote:
@adriancole https://github.com/adriancole Any chance you can create a
jclouds-labs repo to see if we can test how easy it would be from there? I
suspect that will save us a lot of messing around if we don't mind having
the labs code in a different repo...—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1399#issuecomment-14670768
.
@adriancole Thanks!
@adriancole Might want to disable issues and Wiki on the labs repo? Or do we want to track labs project issues there?
OK, so here's what I think we'd need to do for labs:
- Review https://github.com/jclouds/jclouds/pull/1403 and merge
git filter-branchthe result into jclouds-labs- Check that jclouds-labs looks correct (esp. the history)
- Create a 1.6.x release branch for jclouds-labs
- Change the jclouds.version on the release branch to 1.6.0-rc.1 and commit
- Release jclouds-labs 1.6.0-rc.1 off the branch
- Bump the jclouds.version back to 1.6.0-SNAPSHOT on the branch (or merge that in with the release plugin's "back to development version" commit before pushing)
@adriancole note that https://github.com/jclouds/jclouds/pull/1342 also references labs, so if we move it to a separate repo we'd have to pull the PR over there too.
OK, so here's what I think we'd need to do for labs:
Missing steps in there:
- stop making any more changes to jclouds/labs
- closing and re-submitting all PRs to jclouds/labs to the new repo
- removing jclouds/labs from the main repo
OK, getting there ;-) See https://github.com/jclouds/jclouds-labs and https://github.com/jclouds/jclouds-labs/tree/1.6.x. The 1.6.x branch should now be ready to run
mvn release:clean release:prepare -DreleaseVersion=1.6.0-rc.1 -Dtag=jclouds-labs-1.6.0-rc.1 -DdevelopmentVersion=1.6.0-SNAPSHOT -DpushChanges=false
@adriancole Care to take care of the 1.6.0-rc.1 release of jclouds-labs? And what do we want to do then with the labs folder in jclouds (on master and 1.6.x)?
added test results for almost all providers and apis. like usual synaptic-storage (aka atmos) is taking forever and blocking the other tests. https://github.com/jclouds/jclouds.github.com/blob/master/documentation/releasenotes/1.6-tests.md
sure I can take care of it. afterwards, we should delete the labs folder.
-A
staging repo for labs ready for testing. thanks tons, @demobox!
https://oss.sonatype.org/content/repositories/orgjclouds-126/
all tests results from apis and providers are in. worthwhile reviewing: https://github.com/jclouds/jclouds.github.com/blob/master/documentation/releasenotes/1.6-tests.md
staging repo for labs ready for testing
Thanks for taking care of this, @adriancole ! Guess release commits and tags will be pushed after verification?
Yep. @dralves do you mind verifying the above repo!
google-compute in labs works great. thanks @dralves
java -jar target/compute-basics-jar-with-dependencies.jar google-compute 107648139589@developer.gserviceaccount.com "`cat $HOME/google-compute.pem`" mygroup add
>> initializing {id=google-compute, name=Google Compute Engine Api, views=[org.jclouds.compute.ComputeServiceContext], endpointName=https endpoint, identityName=Email associated with the Goole API client_id, credentialName=Optional.of(Private key literal associated with the Google API client_id), documentation=https://developers.google.com/compute/docs, api=interface org.jclouds.googlecompute.GoogleComputeApi, asyncApi=interface org.jclouds.googlecompute.GoogleComputeAsyncApi}
>> adding node to group mygroup
- >> searching params({locationId=us-central1-a, osFamily=gcel, osVersion=1[012].[01][04]})
- << matched image(gcel-12-04-v20130225) hardware(n1-standard-1) location(us-central1-a)
- >> running 1 node group(mygroup) location(us-central1-a) image(gcel-12-04-v20130225) hardwareProfile(n1-standard-1) options({scriptPresent=true})
- >> adding node location(us-central1-a) name(mygroup-b97) image(12357436466894338117) hardware(12907738072351752276)
- << RUNNING node(mygroup-b97)
- >> blocking on sockets [108.59.80.105:22, 10.88.218.197:22] for 600000 MILLISECONDS
- << socket 108.59.80.105:22 opened
- >> running [/tmp/init-bootstrap init] as jclouds@108.59.80.105
- << init(0)
- >> running [sudo /tmp/init-bootstrap start] as jclouds@108.59.80.105
- << start(0)
- << exitstatus(0)
- << customized node(mygroup-b97)
<< node mygroup-b97: [10.88.218.197, 108.59.80.105]
>> running [echo hello] on group mygroup as adriancole
- >> blocking on sockets [108.59.80.105:22, 10.88.218.197:22] for 600000 MILLISECONDS
- << socket 108.59.80.105:22 opened
- >> running [echo hello
] as adriancole@108.59.80.105
- << [statements=[echo hello{lf}]](0)
<< node mygroup-b97: [10.88.218.197, 108.59.80.105]
<< {output=hello
, error=, exitStatus=0}
released labs, and pushed tags
jclouds-chef is in Maven Central
Edited to add link: http://repo1.maven.org/maven2/org/jclouds/chef/chef-project/1.6.0-rc.1/
jclouds-labs in Maven Central
Javadocs (no labs!) available. Permalinks updated:
http://demobox.github.com/jclouds-maven-site/1.6.x/
http://demobox.github.com/jclouds-maven-site/latest/
(http://demobox.github.com/jclouds-maven-site/stable/ still points at 1.5.8)
@adriancole Close this as-is in view of https://github.com/jclouds/jclouds/issues/1456?
Superseded by #1494. Remaining steps will not be completed.