[I elided some of the discussion to focus on the core issues of how development proceeds and our deprecation policy. Other issues has merit but distract from these major points.]
On Thu, Jul 03, 2014 at 11:13:38PM +0000, Everett Toews wrote: > On an example 6 month major release cadence > > 3.0 > 3.1 - 6 weeks > 3.2 - 6 weeks > 3.3 - 6 weeks > 4.0 > > Pre 3.0 you have class Foo you want to replace with class Bar. > > Anytime prior to 3.0 you can make commit (a) to master that adds class Bar > and deprecates Foo which includes the annotation to use Bar and the fact that > Foo will be removed in 4.0. Commit (a) should not be backported. > > Anytime after 3.0 you can make a commit (b) to master that deletes class Foo. > Commit (b) should not be backported. > > That’s it. To me that’s simple and predictable. It always gives users 6 > months to deal with breaking changes and backwards incompatible removals only > happen in major versions. Sorry, I still do not understand and cannot reconcile these paragraphs against earlier mails. Do we branch from master every six months or not? Do we increase the major version every six months? From your example, it appears that we create a 3.x branch from master and continue releasing 3.x from there. 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 don’t think we should optimize around a particularly tangled example. There > can always be exceptions to the policy or guidelines or whatever it is we’re > talking about here though. BlobStore is rotten with such examples and untangling them has proved difficult. How should we deal with clearContainer after removing AsyncBlobStore? How to tame the zoo of Payloads? How to support cancellation of long-lived putBlob and getBlob? BlobStore is the oldest abstraction and has sufficient technical baggage that adding many kinds of features has proved difficult. > Are you working under the idealized assumption that users are tracking > jclouds code very closely and are consuming breaking changes rapidly? I can > guarantee you this is not the case. So many old versions are still in use. Using older versions is not any kind of sin and, while I appreciate users reporting issues only against the current release branch, they should continue to use older jclouds versions. Even your proposed deprecation policy mostly benefits the eager upgraders; perhaps you are working under the idealized assumption that people upgrade at least every six months? A lot of people continue to use 1.6.2, 1.5.0, an even 1.0, and we can do little to help them move forward. > 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. > 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. 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. 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. We disagree whether users should experience new deprecation warnings when upgrading. Second, we disagree whether users should experience breaking changes when upgrading from 3.x to 4.x. We agree that users can experience breakages from 2.x to 4.x, with some intermediate deprecations. Lastly we disagree on whether master can introduce breaking changes at any point, or only after some branching a major release from master. -- Andrew Gaul http://gaul.org/
