[ovs-discuss] time for another LTS?

Benoît benoit at neviani.fr
Sat Jun 22 17:46:54 UTC 2019


Hi,

I found this interesting conversation about LTS.
Perhaps another option would be to use an intermediate version like 2.6 
instead of using a 2.11 if we want to upgrade the current old LTS 
version ?

>On Fri, Oct 19, 2018 at 02:53:53PM -0300, Flavio Leitner wrote:
>> On Fri, Oct 19, 2018 at 08:23:37AM -0700, Ben Pfaff wrote:
>> > On Fri, Oct 19, 2018 at 11:48:07AM +0000, Stokes, Ian wrote:
>> > > > On 10/18/2018 10:46 PM, Ben Pfaff wrote:
>> > > > > I've had a number of queries from folks lately about our roadmap for
>> > > > > LTS releases.  It has, indeed, been a long time since we've had a
>> > > > > long-term support release (the current LTS is 2.5).  Usually, we've
>> > > > > done LTS releases before some kind of big architectural change, etc.,
>> > > > > and so we've had no real internal pressure within the project to do it
>> > > > > for a while.  But it might be a good signal to the community to bring
>> > > > > the LTS release forward.
>> > > > >
>> > > > > What does everyone think about making the next (2.11) release an LTS?
>> > > > >
>> > > > 
>> > > > I think it's a good idea. The current LTS is quite old now, especially for
>> > > > the DPDK datapath. There is a new DPDK LTS coming out in November which
>> > > > should be in for OVS 2.11, so it would be a nice combination for a user to
>> > > > have LTS support for both.
>> > > 
>> > > +1
>> > > 
>> > > With regards backporting support for LTS releases, I take it LTS takes priority over non LTS branches, that would be the only difference I would think?
>> > 
>> > Yes, basically we should try harder to backport to LTS branches.
>> > 
>> > > In fairness I think the community is pretty good as is for backporting
>> > > bug fixes for all branches.
>> > 
>> > We do a pretty good job of it most of the time.  The main driver for LTS
>> > releases has been big OVS internal changes that are likely to break
>> > things.  By doing an LTS release just before a version with those kinds
>> > of changes, we gave our users something to confidently fall back on if
>> > the next release was a little more unstable--not that we ever aim for
>> > that, but it happens sometimes.  We haven't had that kind of big change
>> > recently, so we haven't had a natural impetus to release an LTS--and for
>> > the same reason, it's been easy to backport most fixes because there
>> > haven't been sweeping changes across the tree.
>> 
>> What comes to mind is if OVN manages to split up from OVS soon.
>> Wouldn't be easier if OVN, as a separated project, requires
>> an OVS LTS version? If so, then 2.11 might not be the best one.
>
>That's a good point.  It would be reasonable to designate the first
>version required by the split OVN as LTS.
-- 
Benoit


More information about the discuss mailing list