Open Stack

On 11/20/2014 04:38 PM, Ruby Loo wrote:
> Hi, we had an interesting discussion on IRC about whether or not we
> should be maintaining backwards compatibility within a release cycle. In
> this particular case, we introduced a new decorator in this kilo cycle,
> and were discussing the renaming of it, and whether it needed to be
> backwards compatible to not break any out-of-tree driver using master.
>
> Some of us (ok, me or I) think it doesn't make sense to make sure that
> everything we do is backwards compatible. Others disagree and think we
> should, or at least strive for 'must be' backwards compatible with the
> caveat that there will be cases where this isn't
> feasible/possible/whatever. (I hope I captured that correctly.)
>
> Although I can see the merit (well, sort of) of trying our best, trying
> doesn't mean 'must', and if it is 'must', who decides what can be
> exempted from this, and how will we communicate what is exempted, etc?
It make sense to try to preserve compatibility, especially for things 
that landed some time ago. For newly invented things, like the decorator 
it makes no sense to me, however.

People consuming master have to be prepared. That does not mean that we 
should break them every week obviously, but still. That's why we have 
releases: to promise stability to people. By consuming master you agree 
that things might break rarely.
>
> Thoughts?
>
> --ruby
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>