On Thu, Jul 03, 2014 at 11:24:43PM +0000, Everett Toews wrote: > So only 6 weeks to deal with a breaking change?
In the idealized case of someone upgrading from the last 1.7.x release to the first 1.8.x release, they would have only six weeks notice. Or they stay on their last 1.7.x release for however long they like. Note that breaking changes are not introduced within 1.7.x; applications continue to work from 1.7.1 to 1.7.2 to 1.7.3. Note that we actually have a hole in our deprecation story today as we allow deprecations to 1.7.x branch without requiring a release of it. > If the motivation for making breaking changes in 6 week cycles is because of > this one thing then let’s tear this one off like a bandaid and get it done > for 2.0. It should be dealt with so we can move forward in a stable and > predictable way. I believe you misunderstood my example, I hope the above clarifies it. Note that I am describing the *existing* system, not some hypothetical one. > I disagree with this completely. Semver is well known and well understood > throughout the software industry. Even the C-suite knows that a major release > can contain breaking changes and impact their business. Heck, even the > mainstream populace knows the accessories for version 1 or something won’t > necessarily work with version 2. Being semver compatible is just one of several versioning choices. Many software, including older and existing jclouds releases, use different schemes. Personally I have little interest in the versioning scheme but believe we use of semver should have some justification for breaking with the existing scheme. I do want to repeat my previous sentence and add emphasis: Whether we define and *communicate* that X.0.0 allows breakage or X.Y.0 matters to a vanishingly small number of users... We did not communicate this well previously and might have been doing more work than our users (and some developers?) expected. Perhaps we should draw attention to this compatibility in our release notes for 1.7.x+1 releases? > We’re not just moving numbers around. We’re communicating valuable > information to our users that makes jclouds a predictable platform for them > to build their applications upon. When you look through the Maven dependencies of jclouds or some local application do you know which ones are semver and which are not? You might expect that upgrading from 2.x to 3.x introduces breakages, but not really with x.7 to x.8 and personally I run integration tests on any remotely interesting dependency before upgrading. I have been bitten too many times with even micro version changes, and suspect others have as well. > We can’t expect that every branch from master will increment the major > version. Then what’s the purpose of a major release cadence? Sorry that this repeats from my earlier mail, but I still cannot reconcile how we increment the major number against when we branch. Perhaps you could expand on some of your examples? -- Andrew Gaul http://gaul.org/
