<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 21, 2016 at 10:05 AM, Moran Goldboim <span dir="ltr"><<a href="mailto:mgoldboi@redhat.com" target="_blank">mgoldboi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Jun 21, 2016 at 9:39 AM, Sandro Bonazzola <span dir="ltr"><<a href="mailto:sbonazzo@redhat.com" target="_blank">sbonazzo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sun, Jun 19, 2016 at 3:06 PM, Moran Goldboim <span dir="ltr"><<a href="mailto:mgoldboi@redhat.com" target="_blank">mgoldboi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>my pov - really depends on when do we release 4.1.<br></div>short version (Dec 16) - we should keep it, and 3.6 api as well<br></div>long version (Mar 17) - let's drop it than.<br><br></div>bottom line - we would like to give customers/community the time to migrate their el6 base deployment to el7 , while allowing them dual management infra. by march next year we should be in the 7.4/.next timeframe - this should be ok to our conservative customer base as well<br></div></blockquote><div><br></div></span><div>el6 to el7 host migration should have been done in 3.5. 3.6 doesn't support el6 as hosts...</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>busted here - you are right.. :)<br></div><div>the main point is to allow this deprecation to happen form our integration projects and users side. if we will release early - i would suggest to keep the support for additional version.<br></div></div></div></div></blockquote><div><br></div><div>Keep support for what exactly? What can use the XML-RPC but our own internal tools (such as MOM) which we'll convert?</div><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><div class="h5"><br><br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 19, 2016 at 4:00 PM, Yaniv Dary <span dir="ltr"><<a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What is the cost of keeping them?</div><div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span style="font-family:arial,helvetica,sans-serif">Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : <a href="tel:%2B972%20%289%29%207692306" value="+97297692306" target="_blank">+972 (9) 7692306</a>
8272306
Email: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div><div><div>
<br><div class="gmail_quote">On Sun, Jun 19, 2016 at 3:40 PM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Jun 19, 2016 at 02:13:40PM +0300, Nir Soffer wrote:<br>
> Hi all,<br>
><br>
> We should not support now Engine 3.5 with ovirt 4.0, but vdsm still<br>
> accept 3.5 engines - I guess we forgot to disable it in 4.0.<br>
<br>
</span>Correct. There was a moment in time where we considered supporting 3.5<br>
as well.<br>
<span><br>
><br>
> In 4.1, I don't think we should support any 3.x Engine - otherwise we<br>
> will have to waste time maintaining old apis and infrastructure, instead<br>
> of adding new features that matter to our users.<br>
<br>
</span>Do you have a list of old APIs you'd like to throw away? We've killed a<br>
few in 4.0, and<br>
$ git grep REQUIRED_FOR<br>
is not huge.<br>
<span><br>
><br>
> I suggest we disable now support for 3.x engines.<br>
><br>
> Please see Eli patch:<br>
> <a href="https://gerrit.ovirt.org/59308" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/59308</a><br>
><br>
> Thoughts?<br>
<br>
</span>+1, but let's see if ydary/mgoldboi think we should keep 3.6.<br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div><br></div></div><span>_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br></span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Sandro Bonazzola<br>Better technology. Faster innovation. Powered by community collaboration.<br>See how it works at <a href="http://redhat.com" target="_blank">redhat.com</a><br></div></div></div></div>
</font></span></div></div>
</blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br></blockquote></div><br></div></div>