You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Mario Emmenlauer <ma...@emmenlauer.de> on 2021/09/03 12:45:34 UTC
Linux distros: Support current and previous LTS, deprecated older?
Hi all,
currently thrift builds and tests for Ubuntu 18.04 and 16.04.
The latter is a bit old now. Is there a policy in place what
distro's thrift supports? I think its nice to support the
current LTS, and maybe the previous LTS, but nothing older.
So I propose to switch now from 16.04 to 20.04, and next year
switch from 18.04 to 22.04. There would always be two LTS
tested. What do others think?
Maybe this could also solve some of the build problems (or could
cause new ones, ahaha).
All the best,
Mario Emmenlauer
Re: Linux distros: Support current and previous LTS, deprecated older?
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
I absolutely have no objections to adding 20.04 :)
On Fri, Sep 3, 2021 at 11:26 AM Mario Emmenlauer <ma...@emmenlauer.de>
wrote:
> On 03.09.21 18:03, Yuxuan Wang wrote:
> > According to https://ubuntu.com/about/release-cycle, 16.04 LTS is still
> > currently supported (at least through "Extended Security Maintenance",
> the
> > graph makes it hard to tell whether it's still supported through
> > "Maintenance updates" right now). I think it's probably better to align
> our
> > support policy with upstream (that's how we decided on the Go support
> > policy:
> >
> https://github.com/apache/thrift/blob/master/lib/go/README.md#suppored-go-releases
> > )
> >
> > But of course we have much less resources than Canonical, so if aligning
> > with them creates a burden to us, it's reasonable for us to drop support
> > for old versions more aggressively than them. So if needed our policy can
> > be "we drop support for Ubuntu LTS versions that's in Extended Security
> > Maintenance mode". Which I guess is more or less what you are suggesting
> :)
>
> I see you point with dropping an LTS that is still in the maintenance
> window. My biggest motivation actually is not so much to drop 16.04, but
> rather to add 20.04. I think it would be good to ensure thrift works on
> the current stuff, while remaining backwards compatible as far as we can
> support it.
>
> So actually the more relevant question is: is it fine to add 20.04 to the
> build matrix, and if so, can we "afford" to keep 16.04 too? Travis builds
> may not be a lot slower, but we will burn more minutes per build. Is that
> still reasonable? I'm not sure how many people still use 16.04 nowadays,
> and if they do, whether they need the latest thrift...
>
>
> > (On a side note, for a while recently the only one passing on travis is
> > actually 16.04, so I'd be sad to see it go :) )
>
> Hahaha, ok I will only remove systems in exchange for something that
> builds equally good or better :-) :-)
>
> All the best,
>
> Mario
>
>
> > On Fri, Sep 3, 2021 at 5:45 AM Mario Emmenlauer <ma...@emmenlauer.de>
> wrote:
> >
> >>
> >> Hi all,
> >>
> >> currently thrift builds and tests for Ubuntu 18.04 and 16.04.
> >> The latter is a bit old now. Is there a policy in place what
> >> distro's thrift supports? I think its nice to support the
> >> current LTS, and maybe the previous LTS, but nothing older.
> >> So I propose to switch now from 16.04 to 20.04, and next year
> >> switch from 18.04 to 22.04. There would always be two LTS
> >> tested. What do others think?
> >>
> >> Maybe this could also solve some of the build problems (or could
> >> cause new ones, ahaha).
> >>
> >> All the best,
> >>
> >> Mario Emmenlauer
> >>
> >
>
>
>
> Viele Grüße,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203
> Balanstr. 43 mailto: memmenlauer * biodataanalysis.de
> D-81669 München http://www.biodataanalysis.de/
>
Re: Linux distros: Support current and previous LTS, deprecated
older?
Posted by Mario Emmenlauer <ma...@emmenlauer.de>.
On 03.09.21 18:03, Yuxuan Wang wrote:
> According to https://ubuntu.com/about/release-cycle, 16.04 LTS is still
> currently supported (at least through "Extended Security Maintenance", the
> graph makes it hard to tell whether it's still supported through
> "Maintenance updates" right now). I think it's probably better to align our
> support policy with upstream (that's how we decided on the Go support
> policy:
> https://github.com/apache/thrift/blob/master/lib/go/README.md#suppored-go-releases
> )
>
> But of course we have much less resources than Canonical, so if aligning
> with them creates a burden to us, it's reasonable for us to drop support
> for old versions more aggressively than them. So if needed our policy can
> be "we drop support for Ubuntu LTS versions that's in Extended Security
> Maintenance mode". Which I guess is more or less what you are suggesting :)
I see you point with dropping an LTS that is still in the maintenance
window. My biggest motivation actually is not so much to drop 16.04, but
rather to add 20.04. I think it would be good to ensure thrift works on
the current stuff, while remaining backwards compatible as far as we can
support it.
So actually the more relevant question is: is it fine to add 20.04 to the
build matrix, and if so, can we "afford" to keep 16.04 too? Travis builds
may not be a lot slower, but we will burn more minutes per build. Is that
still reasonable? I'm not sure how many people still use 16.04 nowadays,
and if they do, whether they need the latest thrift...
> (On a side note, for a while recently the only one passing on travis is
> actually 16.04, so I'd be sad to see it go :) )
Hahaha, ok I will only remove systems in exchange for something that
builds equally good or better :-) :-)
All the best,
Mario
> On Fri, Sep 3, 2021 at 5:45 AM Mario Emmenlauer <ma...@emmenlauer.de> wrote:
>
>>
>> Hi all,
>>
>> currently thrift builds and tests for Ubuntu 18.04 and 16.04.
>> The latter is a bit old now. Is there a policy in place what
>> distro's thrift supports? I think its nice to support the
>> current LTS, and maybe the previous LTS, but nothing older.
>> So I propose to switch now from 16.04 to 20.04, and next year
>> switch from 18.04 to 22.04. There would always be two LTS
>> tested. What do others think?
>>
>> Maybe this could also solve some of the build problems (or could
>> cause new ones, ahaha).
>>
>> All the best,
>>
>> Mario Emmenlauer
>>
>
Viele Grüße,
Mario Emmenlauer
--
BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203
Balanstr. 43 mailto: memmenlauer * biodataanalysis.de
D-81669 München http://www.biodataanalysis.de/
Re: Linux distros: Support current and previous LTS, deprecated older?
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
According to https://ubuntu.com/about/release-cycle, 16.04 LTS is still
currently supported (at least through "Extended Security Maintenance", the
graph makes it hard to tell whether it's still supported through
"Maintenance updates" right now). I think it's probably better to align our
support policy with upstream (that's how we decided on the Go support
policy:
https://github.com/apache/thrift/blob/master/lib/go/README.md#suppored-go-releases
)
But of course we have much less resources than Canonical, so if aligning
with them creates a burden to us, it's reasonable for us to drop support
for old versions more aggressively than them. So if needed our policy can
be "we drop support for Ubuntu LTS versions that's in Extended Security
Maintenance mode". Which I guess is more or less what you are suggesting :)
(On a side note, for a while recently the only one passing on travis is
actually 16.04, so I'd be sad to see it go :) )
On Fri, Sep 3, 2021 at 5:45 AM Mario Emmenlauer <ma...@emmenlauer.de> wrote:
>
> Hi all,
>
> currently thrift builds and tests for Ubuntu 18.04 and 16.04.
> The latter is a bit old now. Is there a policy in place what
> distro's thrift supports? I think its nice to support the
> current LTS, and maybe the previous LTS, but nothing older.
> So I propose to switch now from 16.04 to 20.04, and next year
> switch from 18.04 to 22.04. There would always be two LTS
> tested. What do others think?
>
> Maybe this could also solve some of the build problems (or could
> cause new ones, ahaha).
>
> All the best,
>
> Mario Emmenlauer
>