Given the lack of positive feedback to semantic versioning perhaps we should table your proposal until you can convince other developers of its benefits? I do not exactly oppose this idea, but I see its advantages as modest and smaller then the transition costs.
On Tue, Aug 19, 2014 at 10:36:58PM +0000, Everett Toews wrote: > 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 > > > > -- Andrew Gaul http://gaul.org/
