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 -
https://wiki.apache.org/jclouds/1.7.0%20Roadmap

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, etc...so, volunteers needed! =)

A.

Reply via email to