I agree that we should have a major release cadence. I also agree that this is about the predicability of releases but we cannot lose sight of the stability of those releases.
The primary risk of a X month release cadence is how often we make backwards incompatible changes, whether it’s API or behaviour. Being a Java toolkit, jclouds is heavily used in the enterprise and those companies often value stability over many of the other -ilities. I don’t want to see jclouds become that toolkit that companies drop because we break their code base twice a year. I’m *not* saying this is the intention of a major release cadence, but we need to recognize that it’s a possible consequence. How can we mitigate this risk? 1. A clearly communicated deprecation policy. Something along the lines of, in order for something to be removed it has to have been deprecated in a x.1 minor release to be removed in the next X.0 major release. e.g. Changing method signatures in FooApi would mean deprecating the old methods in 3.1 and finally removing those methods in 4.0. 2. A clearly communicated Beta policy. This would be for completely new APIs tagged with the @Beta annotation. These could undergo change more frequently than what’s outlined in the deprecation policy. 3. A better roadmap and better release notes Ignasi touched on the roadmap issue and we’ll need to communicate better in release notes too (I’ve personally tried to do this with regarding the changes to Swift). 4. Embracing patch releases. As Gaul mentioned, most users consume only release versions. I think they would be more willing to accept major release changes more often, if they knew that they could get patch versions more quickly too. I think we would want to restrict patch versions to Blocker, Critical, or security issues. A big barrier to creating patch releases (or any release for that matter) is how manual our release and verification process is. We’re in the process of fixing that. But perhaps for patch releases we can have it be something less than the 72 business hour limit vote. This might be constrained by ASF processes. I’m not sure about that yet. --- The above are not a roadblock for establishing a major release cadence. I would like to see us agree on a path forward for the points and work together on those independently of establishing a major release cadence. I’m on the fence about what the actual cadence should be. 6 months seems a bit short and a year seems too long. Is 9 months an option? Just to compare some example release schedules visually. 9 month major release cadence 3.0 3.1 - 6 weeks 3.2 - 6 weeks 3.3 - 6 weeks 3.4 - 6 weeks 3.5 - 6 weeks 4.0 6 month major release cadence 3.0 3.1 - 6 weeks 3.2 - 6 weeks 3.3 - 6 weeks 4.0 What are some thoughts or questions on all of the above? Thanks, Everett On Jun 20, 2014, at 1:40 AM, Ignasi Barrera <n...@apache.org> wrote: > I agree with both and also vote for a 6 month cadence for majors. > > What I would like for majors is to put some effort in defining a realistic > roadmap (not just a wish list) and work together to complete it. We have > some roadmap definitions in the wiki fruit of the meetups, etc, but I think > we need to have a real plan, for it and work together in its tasks (and use > better the "fixVersion" field in JIRA). > > This is not about the cadence but about the predictability of the releases. > Users should know in advance (when possible) what's going to be in the next > major. Anyway, I think a 6 month cadence is an appropriate one that could > meet most user needs. > El 20/06/2014 00:20, "Andrew Phillips" <aphill...@qrmedia.com> escribió: > >> I propose four potential major release cadences: 6 weeks, i.e., no minor >>> releases, 3 months, 6 months, and 1 year. From my experience 3 or 6 >>> months seems about right, >>> >> >> Given the time it's taken us to pick up some of the larger candidate >> changes for 2.0 (de-asyncing), I'd say 6 months seems more realistic for >> now. >> >> I'd love to propose 3 months, but that's basically once every 2 minor >> releases, which seems a pretty tall order at present. >> >> ap >>
