On 06/16/2014 10:06 PM, James Slagle wrote:
On Mon, Jun 16, 2014 at 12:19 PM, Tomas Sedovic <[email protected]> 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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
