On Jul 7, 2014, at 6:53 PM, Andrew Gaul <g...@apache.org> wrote: > Sorry, I still do not understand and cannot reconcile these paragraphs > against earlier mails. Do we branch from master every six months or > not?
Yes, we branch every 6 months. > Do we increase the major version every six months? Yes, we increment the major version every 6 months. > From your > example, it appears that we create a 3.x branch from master and continue > releasing 3.x from there. I think I see the confusion here. Trying to use text to communicate this was a bad idea. Maybe this diagram clears it up. It’s really not that much different than what we do now except for the major (instead of minor) release cadence. https://docs.google.com/drawings/d/1TDcsLyYPhWpcYEoNo8ohH9AMlpXJB3ywp1CzYCY9C38/edit?usp=sharing > This runs counter to my previous > understanding that master would be 3.x until we branched for the first > breaking change. > > Also I want to expand your example to explain how this will hurt > development on master, specifically diking out bad code. Imagine you > want to removing something like InputStreamMap after 3.0 releases: > > 3.0 > 3.1 - deprecate older API in master > 3.x > 4.0 - master branches to 4.x, commit removal to master > 4.x > 5.x - removal ships to users > > In this example, we delay committing the removal to master for almost > six months (from 3.1 to 4.0) and delay communicating preferred > mechanisms on the release branch for the same interval. Changes are not > isolated and earlier changes block subsequent work, e.g., removing > InputStreamMap enabled some ByteSource changes. Not being able to push > these changes to master will make development much harder. Use of extra > development branches partially addresses this, although does not publish > these changes to all developers. I’m aware of this scenario and I would argue that it can be mitigated by better planning. If the deprecation and been well planned, it would have landed just prior to 3.0 and then the removal ships to users in 4.0. I realize that historically we haven’t been very good at planning but I don’t think that’s a good reason to not try to get better at this stuff. >> Not having a predictable deprecation policy guarantees that users will be >> more likely to stay marooned on old versions because they’ll have no idea at >> what point things will break on them. > > Perhaps we did not communicate this clearly, but jclouds has had a > predictable deprecation policy for at least the last three years. Users > can upgrade from an earlier 1.7.x release to a later 1.7 release and > breaking changes were only introduced in 1.8.0. Sometimes a given 1.7.x > release contained new deprecation annotations but otherwise applications > continue to work. Despite this, users choose not to upgrade to the > latest micro releases. When you follow something reasonably close to semver you don’t have to worry about this kind of communication because everybody already knows it. Every time I encounter a new project I automatically assume semver unless it’s otherwise stated because there’s really no alternative assumption to make. I’d argue that this is what most developers do. >> I think making potentially breaking changes every 6 months is actually very >> progressive in the world of Java. I think it’s a good trade off between >> providing a stable and predictable platform for users to build the >> businesses upon vs improving that platform in backwards incompatible ways. > > I believe that providing flexibility to evolve jclouds will benefit our > future users as well as existing ones. Shackling ourselves to > restrictive deprecation policies hurts a fair number of people who > prefer to use a more rational cloud abstraction. Just as throwing it open to making deprecations at any point hurts a fair number of people who prefer to use a more stable and predictable cloud abstraction. > I believe some > positive changes simply will not happen with the proposed system. > > In the interests of not talking past each other, I want to summarize > some points in this thread as I understand them. Thanks for this. Agreed that we need to focus the discussion a bit more. So I’m only going to reply to this email to keep us on one email thread. > First, we all agree > that users upgrading from an earlier 3.x should be able to use a later > 3.x release without source modification. Yes. Agreed. > We disagree whether users > should experience new deprecation warnings when upgrading. Yes. We disagree. My main point of contention here is that there needs to be a minimum amount of time for users to react to changes. You feel that 6 weeks is acceptable, such as in the case of 3.3 to 4.0. I feel that 6 weeks is far too short and have been arguing for 6 months. > Second, we > disagree whether users should experience breaking changes when upgrading > from 3.x to 4.x. I’m not so sure we disagree here. Because users are upgrading across a major release boundary there could be breaking changes. But breaking changes should only be in 4.0 and *not* in 4.1, 4.2, or 4.3. > We agree that users can experience breakages from 2.x > to 4.x, with some intermediate deprecations. Yes. We agree (with my same caveat about breaking changes above). > Lastly we disagree on > whether master can introduce breaking changes at any point, or only > after some branching a major release from master. Yes. We disagree. This goes back to my main point of contention. Again, to me it really seems like the BlobStore is your main concern for being able to break things more quickly in order to rapidly improve the existing code. The ComputeService and other APIs don’t seem to be in such a state in general. What if you could work on the BlobStore and deprecate at any point between 2.0 and 3.0? If the BlobStore API had stabilized by 3.0 then perhaps it could move to the more conservative deprecation proposal. Thoughts? Regards, Everett
