Open Stack

On Tue, Jul 28, 2015 at 09:55:03PM -0400, Julia Kreger wrote:
> > So if we do this, simply shipping the code doesn't break anyone. Nobody
> > has disagreed on this yet, best I can tell.
> >
> > So let's ship some code. :)
> >
> > // jim
> >
> >
> I'm not sure we can just ship some code, unless I've missed something in
> the discussion, at some point a user/operator workflow could still break if
> a future user client is upgraded with the current server code.   Now if
> this is something the Ironic community is willing to accept, as I
> personally thought was originally the case, then that is another matter.
> 
> My $0.02 is that forcing a workflow change should be handled with a
> deprecation period while avoiding the hard breaking change for the user
> workflow, because it is akin to taking away a feature, or in this case,
> forcing the user to use a feature they may not want nor need.
> 
> What if we revert 523da21cd3f5fc3299f9b91ac6d885f0fb54eddb and
> 1410e59228c3835cfc4f89db1ec482137a3cfa10 in order to cut a release, then
> revert the reverts while layering on top a server side fix to remove the
> hard break for users?

So that's the other part here - even if we have a way to make 1.11
easier for users to swallow, we can't. There are people that deploy
master out there, so we need to treat master as already released. If we
change how the enroll API works (again), that needs to be 1.12. If we
revert it, that also needs to be 1.12, with 1.11 carrying the current
code.

// jim