Robert Collins wrote: > On 23 September 2015 at 02:03, Thierry Carrez <thie...@openstack.org> wrote: >> Robert Collins wrote: >>> [...] >>> So, one answer we can use is "The version impact of a requirements >>> change is never less than the largest version change in the change." >>> That is: >>> nothing -> a requirement -> major version change >> >> That feels a bit too much. In a lot of cases, the added requirement will >> be used in a new, backward-compatible feature (requiring y bump), or >> will serve to remove code without changing functionality (requiring z >> bump). I would think that the cases where a new requirement requires a x >> bump are rare. > > So the question is 'will requiring this new thing force any users of > the library to upgrade past a major version of that new thing'. If its > new to OpenStack, then the answer is clearly no, for users of the > library within OpenStack, but we don't know about users outside of > OpenStack'. I am entirely happy to concede that this should be case by > case though. > >>> 1.x.y -> 2.0.0 -> major version change >>> 1.2.y -> 1.3.0 -> minor version change >>> 1.2.3. -> 1.2.4 -> patch version change >> >> The last two sound like good rules of thumb. > > What about the one you didn't comment on ? :)
Damn, you got me. Hmm... "it depends" ? I think we can't really have a default rule for a major bump. Depending on how the library is used, it could trigger anything. Defaulting to a major bump as a result sounds a bit overkill. -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev