Open Stack

I think it depends totally on if you want trunk to be a distribution mechanism or not. If you encourage people to 'just use trunk' for deployment, then you better not break out of tree drivers on people. If you have a stable release branch, that you tell people to use, there is plenty of forewarning for out of tree drivers to update when the new stable is about to be released.

Thanks,
Kevin
________________________________________
From: Lucas Alvares Gomes [lucasagomes at gmail.com]
Sent: Thursday, November 20, 2014 8:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle

Hi Ruby,

Thank you for putting this up.

I'm one of the ones think we should try hard (even really hard) to
maintain the compatibility on every commit. I understand that it may
sound naive because I'm sure that sometimes we will break things, but
that doesn't means we shouldn't try.

There may be people running Ironic in a continuous deployment
environment, those are the users of the project and therefor the most
important part of Ironic. Doesn't matter how well written Ironic code
may be if nobody is using it. If we break that user workflow and he's
unhappy that's the ultimate failure.

I also understand that in the project POV we want to have fast
interactions and shiny new features as quick as possible and trying to
be backward compatibility all the time - on every commit - might slow
that down. But in the user POV I believe that he doesn't care much
about all the new features, he would mostly care about the things that
used to work to continue to work for him.

Also the backwards approach between releases and not commits might
work fine in the non-opensource world where the code is kept indoors
until the software is release, but in the opensource world where the
code is out to people to use it all the time it doesn't seem to work
that well.

That's my 2 cents.

Lucas

On Thu, Nov 20, 2014 at 3:38 PM, Ruby Loo <rlooyahoo at gmail.com> 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?
>
> Thoughts?
>
> --ruby
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev