Open Stack

Robert Collins wrote:
> On 23 September 2015 at 02:03, Thierry Carrez <thierry at 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)