Open Stack

On 06/16/2014 10:06 PM, James Slagle wrote:
> On Mon, Jun 16, 2014 at 12:19 PM, Tomas Sedovic <tsedovic at redhat.com> wrote:

>> If we do promise backwards compatibility, we should document it
>> somewhere and if we don't we should probably make that more visible,
>> too, so people know what to expect.
>>
>> I prefer the latter, because it will make the merge.py cleanup easier
>> and every published bit of information I could find suggests that's our
>> current stance anyway.

> Much of this is the reason why I pushed for the stable branches that
> we cut for icehouse. I'm not sure what "downstreams that have shipped
> things" are being referred to, but perhaps those needs could be served
> by the stable/icehouse branches that exist today?  I know at least for
> the RDO downstream, the packages are being built off of releases done
> from the stable branches. So, honestly, I'm not that concerned about
> your proposed changes to rip stuff out without any deprecation from
> that point of view :).

+1 on relying on the branches

I personally don't see the backward compatibility much of an issue in 
TripleO (but I may miss some pieces though) ... more below

> That being said, just because TripleO has taken the stance that
> backwards compatibility is not guaranteed, I agree with some of the
> other sentiments in this thread: that we should at least try if there
> are easy things we can do.

 From a the 10.000 feet view, I can imagine people relying on a stable 
API for services like Cinder but I don't see how that applies to TripleO

Why should one try to install an older version of OpenStack using some 
'recent' version TripleO?

The only scenario which comes up to my mind is the 'upgrade' process 
where undercloud and overcloud could get 'out of sync', yet this seems 
to have a pretty limited scope.

A genuine question from a 'wannabe' TripleO contributor, do you see 
others? many others?
-- 
Giulio Fidente
GPG KEY: 08D733BA