On Jul 2, 2014, at 5:58 PM, Andrew Gaul <g...@apache.org> wrote: > The current system seems fine: giving users compatibility across micro > versions, e.g., 1.7.x -> 1.7.x + 1, and giving users a heads up at least > one micro release via @Deprecated annotations.
So only 6 weeks to deal with a breaking change? > Most of our users won't > know our deprecation policy further than these annotations so doing more > seems pointless. Agreed. All deprecation annotations should include what the deprecated thing has been replaced with and when it will be removed. > Further some of the interfaces that jclouds provides > today are incorrect, e.g., Payload implements InputSupplier.getInput but > opts out the repeatable guarantee via isRepeatable then provides > confusing semantics to getInput and release. Fixing these while > providing best-effort compatibility is a large challenge; doing so with > strong compatibility might not be possible other than the strawman of > percolating new Payload2 interfaces throughout jclouds. 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. > Semver is an academic distinction. Whether we define and communicate > that X.0.0 allows breakage or X.Y.0 matters to a vanishingly small > number of users: their application will have breakage when upgrading in > either case. jclouds can go this way but we should expect that every > branch from master will increment the major version and just define > minor releases away. Although then we are basically back to where we > started just with numbers moved around! 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. 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. We can’t expect that every branch from master will increment the major version. Then what’s the purpose of a major release cadence? Regards, Everett
