All sounds good to me, just one question and two comments. Question: Does jclouds (or apache in general) follow the Semantic Versioning Specification <http://semver.org/> or the similar Apache Portable Runtime Versioning Standard <http://apr.apache.org/versioning.html>? I believe in either a +0.1.0 change adds functionality but maintains backwards compatibility. A +1.0.0 change includes API changes that break backwards compatibility.
Comment: I like cadences, but only as a *maximum *duration between releases. I think more frequent releases may be rare, but if you hit a streak of new features or major performance improvements every two weeks, it should be an option. Comment: I assume nightly or continuous builds (like ant and ivy<http://ant.apache.org/nightlies.html> or other apache projects) can still happen. Just like they say: *"Ant and Ivy are using Continous Integrations systems to improve the development process. Note that these are no official builds and they are not endorsed or even supported by the Ant team. But if you have problems with testing the latest (successful) build, you are welcome to post that on the developer mailing list."* This is a useful for dependent projects, especially if they use jenkins or travis-ci matrix builds (which let them test against both the latest build and the latest official release). On Tue, Jun 25, 2013 at 10:40 AM, Everett Toews <everett.to...@rackspace.com > wrote: > 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> >
