On Wed, Jul 02, 2014 at 11:28:33PM +0200, Andrew Phillips wrote: > >Strong promises of compatibility will discourage many (breaking) > >improvements, big and small. I worry about this a lot given the > >existing quirky jclouds API and the large about of suboptimal API use I > >observe in Stack Overflow questions and jclouds-user mails. > > Thanks a lot for this, Gaul - I think this is exactly the kind of > discussion (i.e. which kind of a tradeoff are we looking for) we > want to be having here! > > As far as I'm concerned, everything suggested so far is exactly that > - a suggestion - so if we feel it's not the right tradeoff to be > making at this time, let's try to come up with something else. > > What would you suggestion be?
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. Most of our users won't know our deprecation policy further than these annotations so doing more seems pointless. 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. > ap > > PS: Also agree that the first step towards semver is "moving a > number around". But even if that doesn't affect any other > development practice, it still seems like a step in the right > direction..? ;-) 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! -- Andrew Gaul http://gaul.org/
