atom feed9 messages in org.apache.jclouds.userProposal for Apache jclouds release c...
FromSent OnAttachments
Andrew BayerJun 24, 2013 4:03 pm 
Andrew BayerJun 24, 2013 4:35 pm 
Everett ToewsJun 25, 2013 6:40 am 
Max LincolnJun 25, 2013 7:14 am 
Andrew BayerJun 25, 2013 8:34 am 
Zack ShoylevJun 25, 2013 9:03 am 
Andrew GaulJun 25, 2013 9:21 am 
Max LincolnJun 25, 2013 9:54 am 
Zack ShoylevJun 25, 2013 11:12 am 
Subject:Proposal for Apache jclouds release cadence and 1.7.0 roadmap/schedule/RM
From:Andrew Bayer (
Date:Jun 24, 2013 4:03:11 pm

So, this came up on IRC and it seems like it should be proposed here on the list. =)

We should have a regular release cadence, at least for maintenance releases of the current stable release (i.e., currently, the 1.6.x train). That will let us be sure of roughly how long it'll be before a fix is available in a release once that fix goes in - that's awfully handy for the downstream consumers of jclouds, so they can know when they'll be able to incorporate the fixes into their own releases.

The consensus on IRC is to aim at a 6 week cadence for maintenance releases - with the clock starting when the previous release officially releases. That would mean that the clock started last Wednesday for 1.6.2-incubating, and it'll be scheduled for Wednesday, August 1st. Now, obviously, the scheduling won't be perfect - we'll have to deal with a week or so for release votes and iterations of RCs, but we can keep that from blocking changes for the next maintenance release by doing releases off a 1.6.2 (etc) branch. And I am willing to guarantee that the next release will have a *much* faster turnaround than 1.6.1-incubating did. =)

What do you all think about this idea?

On a related note, I'd also like to try to come up with a target date for 1.7.0 release (and there is a real possibility we'll shift that to 2.0.0, given the package name changes, but that's neither here nor there), and along with that, a roadmap for what exactly will be done for 1.7.0. I personally think that setting a target date will make it a lot easier for us to limit our ambitions for the roadmap, so I'm going to propose a very tentative date of October 1st, with the understanding that there's almost no chance we actually release then. =) I've also put up a wiki page for collecting roadmap ideas/concrete plans/etc -

I should mention that I will almost certainly *not* be able to release-manage 1.7.0, on account of being out of town from around October 8th until just about the end of the month, and for two weeks of that, I'll be driving around Central Europe with my mom. Soooooo, yeah. It'd be great if someone would be willing to step up and be RM for 1.7.0 - that's probably going to be a harder job than being 1.6.2 RM, since someone's got to build consensus around the feature roadmap and then build consensus on what gets dropped when it's not ready on time vs what we delay the release for,, volunteers needed! =)