release jclouds 1.6.0-rc.3 about legacy-jclouds HOT 40 CLOSED

Repo ready for testing https://oss.sonatype.org/content/repositories/orgjclouds-223

from legacy-jclouds.

If this goes through, time to close out https://github.com/jclouds/jclouds/issues/1456 and https://github.com/jclouds/jclouds/issues/1399 (rc.1 and rc.2 release issues)?

from legacy-jclouds.

sure.

On Thu, Apr 4, 2013 at 9:46 AM, Andrew Phillips [email protected]:

If this goes through, time to close out #1456https://github.com/jclouds/jclouds/issues/1456and
#1399 https://github.com/jclouds/jclouds/issues/1399 (rc.1 and rc.2
release issues)?

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1494#issuecomment-15909147
.

from legacy-jclouds.

validated repo by testing compute-basics with aws-ec2 and blobstore-basics with cloudfiles-us

from legacy-jclouds.

per @andrewgaul good to go

from legacy-jclouds.

Ran Maginatics smoke tests against against these blobstores: aws-s3, azureblob, cloudfiles-uk, cloudfiles-us, filesystem, hpcloud-objectstorage, synaptic-atmos, and transient.

from legacy-jclouds.

In Maven Central. Thanks, @adriancole !

from legacy-jclouds.

planning to cut jclouds-labs in 1hr. speak up now, if there are any missing commits. Note we will certainly have an rc.4 so no big deal.

from legacy-jclouds.

planning to cut jclouds-labs in 1hr

Coolio. Note you'll have to have a pre-commit to first set the jclouds.version to 1.6.0-rc.3 and then another one afterwards to set it back to snapshot. See jclouds/jclouds-labs@a7b6a2c and jclouds/jclouds-labs@2aacf31.

Also, want to cherry-pick Matt's POM-simplification commit to 1.6.x or leave that on master?

from legacy-jclouds.

I started uploading already, but this is a better idea. going to cherry-pick and start again.

from legacy-jclouds.

I started uploading already

Note to self: that's what happens when you don't keep up with GitHub messages ;-)

from legacy-jclouds.

there were a series of problems in the labs poms relating to osgi imports being accidentally named based on maven artifacts instead of packages. I'll issue a PR against 1.6.x in a minute.

from legacy-jclouds.

ok pull request for labs to fix the poms. when this gets +1'd I can start the release
jclouds/jclouds-labs#27

from legacy-jclouds.

somebody else needs to do labs, I've starved all day on osgi, pom crap and out of time. sorry guys.

from legacy-jclouds.

I've starved all day on osgi, pom crap and out of time.

What a diet! ;-) Will try to help later if I can. Will check the PRs first...

from legacy-jclouds.

Will try to help later if I can. Will check the PRs first...

Sorry, got stuck in a late-night refactoring session :-( And given Ioannis comment on jclouds/jclouds-labs#27, still wondering whether that part of the PR should be included or ignored for now.

from legacy-jclouds.

I can revert all osgi fixes if we want. We no longer use class.forName
since v1.4 so I think we would make identical changes later.

On Saturday, April 6, 2013, Andrew Phillips wrote:

Will try to help later if I can. Will check the PRs first...

Sorry, got stuck in a late-night refactoring session :-( And given Ioannis
comment on jclouds/jclouds-labs#27jclouds/jclouds-labs#27,
still wondering whether that part of the PR should be included or ignored
for now.

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1494#issuecomment-15996562
.

from legacy-jclouds.

p.s. we should not block chef, karaf, and cli on labs. Let's get this release out and skip labs if need be. I'd really hate to have yet another incomplete rc on account of labs.

from legacy-jclouds.

in fact, I'm taking labs out of the todo list, as fundamentally our release should never be blocked on labs as that can always go out later.

from legacy-jclouds.

jclouds-chef repo ready for testing: https://oss.sonatype.org/content/repositories/orgjclouds-598/

from legacy-jclouds.

(closed accidentally, the buttons are too close! :)) jclouds-chef repo ready for testing: https://oss.sonatype.org/content/repositories/orgjclouds-598/

from legacy-jclouds.

jclouds-chef repo verified and tested with Abiquo and Hosted chef. Awaiting Maven Central sync.

from legacy-jclouds.

p.s. I'd recommend releasing the current state of jclouds-labs else pretty soon it will be impossible to release 1.6.0-rc.3 there anymore due to in-flight changes on jclouds/jclouds 1.6.0-SNAPSHOT

from legacy-jclouds.

otherwise, completely skip labs rc.3; either way is fine with me

from legacy-jclouds.

jclouds-chef in Maven Central.

from legacy-jclouds.

When releasing labs, we should tag this commit. The next one is after 1.6.0-rc.3 and is not part of the release; the build will fail if releasing a later version.
If I have time I'll try to release labs today.

from legacy-jclouds.

As mentioned here there are poms in branch 1.6.x of labs that have 1.7.0-SNAPSHOT versions:

~/src/jclouds-labs ((2aacf31...)) $ find . -name pom.xml -exec grep -nH '1.7.0' {} \;
./opsource-servers/pom.xml:27:    <version>1.7.0-SNAPSHOT</version>
./greenqloud-compute/pom.xml:27:        <version>1.7.0-SNAPSHOT</version>
./nodepool/pom.xml:27:    <version>1.7.0-SNAPSHOT</version>
./savvis-symphonyvpdc/pom.xml:27:        <version>1.7.0-SNAPSHOT</version>
./smartos-ssh/pom.xml:27:        <version>1.7.0-SNAPSHOT</version>
./rackspace-clouddns/pom.xml:27:    <version>1.7.0-SNAPSHOT</version>
./carrenza-vcloud-director/pom.xml:27:        <version>1.7.0-SNAPSHOT</version>
./azure-management/pom.xml:27:    <version>1.7.0-SNAPSHOT</version>
./cloudstack-ec2/pom.xml:27:    <version>1.7.0-SNAPSHOT</version>
./jenkins/pom.xml:27:    <version>1.7.0-SNAPSHOT</version>
./greenqloud-storage/pom.xml:27:        <version>1.7.0-SNAPSHOT</version>

Should we:

• Skip labs 1.6.0-rc.3 release until this is fixed?
• Release labs leaving this incorrect poms?
• Fix them, and release with the fix? (Take into account that the fix needs to be applied to the commit mentioned in the commit above).

from legacy-jclouds.

Doesn't the release plugin ask to resolve snapshot versions? If so, we
could fix the 1.7 versions to 1.6.0-RC.3 that way, right?

On Tuesday, April 9, 2013, Ignasi Barrera wrote:

As mentioned herehttps://github.com/jclouds/jclouds-labs/pull/15#issuecomment-15998241there are poms in branch 1.6.x of labs that have 1.7.0-SNAPSHOT versions:

~/src/jclouds-labs ((2aacf31...)) $ find . -name pom.xml -exec grep -nH '1.7.0' {} ;
./opsource-servers/pom.xml:27: 1.7.0-SNAPSHOT
./greenqloud-compute/pom.xml:27: 1.7.0-SNAPSHOT
./nodepool/pom.xml:27: 1.7.0-SNAPSHOT
./savvis-symphonyvpdc/pom.xml:27: 1.7.0-SNAPSHOT
./smartos-ssh/pom.xml:27: 1.7.0-SNAPSHOT
./rackspace-clouddns/pom.xml:27: 1.7.0-SNAPSHOT
./carrenza-vcloud-director/pom.xml:27: 1.7.0-SNAPSHOT
./azure-management/pom.xml:27: 1.7.0-SNAPSHOT
./cloudstack-ec2/pom.xml:27: 1.7.0-SNAPSHOT
./jenkins/pom.xml:27: 1.7.0-SNAPSHOT
./greenqloud-storage/pom.xml:27: 1.7.0-SNAPSHOT

Should we:

• Skip labs 1.6.0-rc.3 release until this is fixed?
• Release labs leaving this incorrect poms?
• Fix them, and release with the fix? (Take into account that the fix
  needs to be applied to the commit mentioned in the commit above).

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1494#issuecomment-16099119
.

from legacy-jclouds.

Right, we can then release as you said, and fix the poms in HEAD.

from legacy-jclouds.

@nacx this is fixed in labs HEAD, and shouldn't arise again. I would suggest refactoring labs 1.6.x branch to the parenting model in HEAD.

from legacy-jclouds.

When releasing labs, we should tag this commit

@nacx Shouldn't we tag the commit where both jclouds.version and project.version are set to the "release" version, i.e. 1.6.0-rc.3? That would be the "regular" Maven release commit, no?

from legacy-jclouds.

@demobox sure, what I meant is that we should start the release process in that commit, instead of the 1.6.x HEAD. I didn't express it properly :)

Next thing is that even if the maven-release-plugin fixes the 1.7.0-SNAPSHOT versions to the right 1.6.0-rc.3, those projects also have an incorrect parent. They are pointing to the jclouds-project pom (which is also outside the labs git repository).

This is already fixed in #44, but for this release I think we should change the parent configuration to point to the jclouds-labs-project pom, like in the rest of labs projects.

I've already made the changes, but I'll wait for some opinions +1's before releasing and tagging with these changes.

from legacy-jclouds.

@nacx I think the problem for most of these is that they are simply not part of the current jclouds-labs module set:

<modules>
   <module>virtualbox</module>
   <module>vcloud-director</module>
   <module>elb</module>
   <module>aws-elb</module>
   <module>dmtf</module>
   <module>cdmi</module>
   <module>joyent-cloudapi</module>
   <module>joyentcloud</module>
   <module>google-compute-engine</module>
   <module>iam</module>
   <module>aws-iam</module>
   <module>rds</module>
   <module>aws-rds</module>
   <module>fgcp</module>
   <module>fgcp-au</module>
   <module>fgcp-de</module>
   <module>abiquo</module>
   <module>oauth</module>
   <module>openstack</module>
   <module>rackspace-clouddns</module>
</modules>

In that case, they should be ignored by the release plugin anyway. I'm assuming the omissions are deliberate, by the way, but @adriancole probably has more info on that.

from legacy-jclouds.

The two buttons being so close is killing me :)

The maven-release-plugin ignores them, so the version will remain unchanged and the artifacts are not going to be uploaded to the Maven Central, so we could leave them unchanged If we wanted.

The only thing to take into account is that the tag will be created with the released projects in 1.6.0-rc.3 and the other ones in 1.7.0-SNAPSHOT.

from legacy-jclouds.

The only thing to take into account is that the tag will be created with the released projects in 1.6.0-rc.3 and the
other ones in 1.7.0-SNAPSHOT.

I can live with that. The tag should allow you to recreate the artifacts that were released for that version. That there may be other code in that tag unrelated to the released artifacts seems OK to me.

from legacy-jclouds.

I can live with that, too. I hope some projects migrate to their own repos
for RC.4 as well :)

On Tuesday, April 9, 2013, Andrew Phillips wrote:

The only thing to take into account is that the tag will be created with
the released projects in 1.6.0-rc.3 and the
other ones in 1.7.0-SNAPSHOT.

I can live with that. The tag should allow you to recreate the artifacts
that were released for that version. That there may be other code in that
tag unrelated to the released artifacts seems OK to me.

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1494#issuecomment-16116924
.

from legacy-jclouds.

Javadocs available

from legacy-jclouds.

@adriancole @nacx Are we planning to do any more work on this?

from legacy-jclouds.

No

On Tuesday, May 7, 2013, Andrew Phillips wrote:

@adriancole https://github.com/adriancole @nacxhttps://github.com/nacxAre we planning to do any more work on this?

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds/issues/1494#issuecomment-17543560
.

from legacy-jclouds.

No

Will close. Please reopen if more work does happen to come along.

from legacy-jclouds.