This was the important part: - timed feature releases - timed bugfix releases in-between
Version strings: semver looks right for jclouds (SDKs, maven packaging), however it might make sense to also "unofficially" name feature releases with a month/year. Zack ________________________________ From: Max Lincoln [mlinc...@thoughtworks.com] Sent: Tuesday, June 25, 2013 11:54 AM To: user@jclouds.incubator.apache.org Cc: d...@jclouds.incubator.apache.org Subject: Re: Proposal for Apache jclouds release cadence and 1.7.0 roadmap/schedule/RM Zack - with semver: "Major release" - breaks API "Minor release" - adds features but does not break (existing feature) API "Patch" - backwards-compatible bug fixes or performance improvements So my expectation would be: Patch cadence: ASAP at least for critical issues (especially for security issues). Minor cadence: Every 6 weeks Major cadence: I'm not sure this is necessary, but if you think there are a lot of breaking changes coming up you could say something like "we won't break the API more than twice a year". On Tue, Jun 25, 2013 at 1:03 PM, Zack Shoylev <zack.shoy...@rackspace.com<mailto:zack.shoy...@rackspace.com>> wrote: Maintenance releases every 6 weeks - what is the expectation for major releases? I have worked with projects that did those very regularly (April August December) and that helped users be ready to upgrade very regularly. The major releases were also month code-named which made it intuitive. This is in addition to semantic versioning. Zack ________________________________________ From: Everett Toews [everett.to...@rackspace.com<mailto:everett.to...@rackspace.com>] Sent: Tuesday, June 25, 2013 8:40 AM To: <d...@jclouds.incubator.apache.org<mailto:d...@jclouds.incubator.apache.org>> Cc: <user@jclouds.incubator.apache.org<mailto:user@jclouds.incubator.apache.org>> Subject: Re: Proposal for Apache jclouds release cadence and 1.7.0 roadmap/schedule/RM On Jun 24, 2013, at 6:03 PM, Andrew Bayer wrote: So, this came up on IRC and it seems like it should be proposed here on the list. =) 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. +1 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. =) +1 I've also put up a wiki page for collecting roadmap ideas/concrete plans/etc - https://wiki.apache.org/jclouds/1.7.0%20Roadmap Why use the wiki for this? Why not use the Roadmap feature in JIRA [1]? Isn't that what it's for? If we put it in the wiki, then we've got to manage this stuff in two places. I should mention that I will almost certainly *not* be able to release-manage 1.7.0 I'll be out of town from Sept. 23 to Oct. 4. It's our 10th wedding anniversary so it's very much set in stone. ;) Everett [1] https://issues.apache.org/jira/browse/JCLOUDS#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel<https://issues.apache.org/jira/browse/JCLOUDS#selectedTab=com.atlassian.jira.plugin.system.project:roadmap-panel>
