Let’s see what we can agree on and move forward on those points. 1. 6 month major release cadence.
That would mean the next releases are roughly: * 2.0.0 mid-Sept * 2.1.0 early-Nov * 2.2.0 late-Dec * 2.3.0 mid-Feb * 3.0.0 early-Mar 2. Minor point upgrades do not introduce breaking changes. e.g. "users upgrading from an earlier 3.x should be able to use a later 3.x release without source modification.” (pasted from Gaul’s previous email below). Can everyone agree on those two points? Regards, Everett On Jul 11, 2014, at 11:45 PM, Everett Toews <everett.to...@rackspace.com> wrote: > 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 > >
