On Wed, Jul 02, 2014 at 07:22:09PM +0000, Everett Toews wrote: > Basically I’m looking for a guaranteed *minimum* amount of time for users to > be able to react to breaking changes. Considering the long release cycles in > place at many organizations, I think 6 months is the absolute minimum. > > If we had a 6 month major release cadence, announcing upcoming breaking > changes on major release (X.0 only) would be necessary. > > If we had a 9 month major release cadence, announcing upcoming breaking > changes on major release or the two releases after (X.0, X.1, and X.2 only) > would be possible.
Giving a date-based notice as Guava does for some recent breakages, e.g., InputSupplier scheduled for removal in December 2015, makes some amount of sense given jclouds historical lack of major release predictability. However, I generally doubt that we can provide strong guarantees about breakages while addressing the large backlog of jclouds technical debt and relying on Guava deprecated and beta APIs. Further I do not understand the proposed workflow for changing or removing an API. Let's assume we are at 1.7.3 as today and will release 1.8.0 in a month, and new major versions every six months. At which point in the development cycle can I commit a breaking change to master: 1) at any point before 1.8.0 release 2) immediately after 1.8.0 release 3) at any time during 1.8.x 4) when someone changes the project version to 2.0.0 Previously we allowed 1-4 but the proposed scheme only allows for 4? When do we decide to bump the major version number and which fraction of the release cycle allows breaking changes? Also consider a more complicated example, I tried to accommodate the most number callers when moving from InputSupplier to ByteSource but strongly suspect that I caused breakages for several users and I still have not completed this work. How would we address this under the proposed scheme, given that Payload *implements* the deprecated InputSupplier interface, other than introducing a new Payload2 class. > > Curious to hear what others feel about that? > > Me too. Perhaps it’s lazy consensus at work. :) This discussion discourages me since it discusses some idealized breakage policy and does not connect to the reality of where jclouds exists. Going forward this semantic versioning discipline and ongoing API changes will ensure that we bump the major release number (MAJOR.y.z) every time instead of the minor one (x.MINOR.z) but this does not really do anything for users except for moving a number around. 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. -- Andrew Gaul http://gaul.org/
