kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

I would probably personally prefer if we kept it at 1.59 instead of
dropping it back (I hope to improve the unit testing of the tool framework,
so having the better testing library would make that easier), but we need
to be consistent with the support lifetimes we use. If 16.04 is supported
doesn't affect me personally (I run Fedora at home and 18.04 at work*).
Perhaps defining an official rule for the LTS releases like "Officially
supported until the next LTS release + 6 months" might be good (e.g. 16.04
is supported until 10/18 and 18.04 is supported until 10/20) to give users
time to upgrade but also not be constrained by libraries from >4 years ago.

-Ian

* It used to be 16.04, but then I needed to upgrade Matlab and all of a
sudden the version of the standard library that Matlab provided was newer
than the system one. When that happens, you know your OS is old.

On Wed, Oct 23, 2019 at 1:05 AM Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:

> On 2019-10-22 16:06, Ian McInerney wrote:
>
> I dug into the website history and apparently the original intent should
> have been to support 16.04 LTS until its standard support ends in 2021 (
> https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782).
> Since we haven't actually used any code from the newer Boost version (that
> we weren't already using), we should probably back out the change and also
> update the website with the correct Ubuntu LTS support date. It looks like
> that will make it so we can't update to 1.59 until 2021 then.
>
>
>
> Hi Ian-
>
> I did write that.  In retrospect, I'm not sure that the sentiment is
> correct.  One of the things we are attempting to do is focus our primary
> efforts where they will have the largest impact for our users.  Toward that
> end, we were attempting (in the post KiCon meeting) to define where that
> cut off should be.  We kind of arbitrary picked "vendor supported" as it
> seemed reasonable.
>
> I now think we should tighten that a bit more for the Linux
> distributions.  Under MSW/Mac, we compile or have rolling updates for most
> of our own dependencies.  This allows us to ensure system compatibility but
> not worry about library compatibility.  The Linux library system is
> different and holds back updates.
>
> So, why would we want to update the boost libraries and what does it gain
> us?  The original bump was to allow unit tests.  During v6, I would also
> like to utilize the UUID library from 1.60 as many of the feature we plan
> will require GUID at least.
>
> This doesn't preclude using KiCad on 16.04.  It just requires someone to
> package a boost ppa.  There are a few out there that could be used as
> baselines for this.
>
> -Seth
>
>
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.com    info@xxxxxxxxxxxxx
> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA>
> https://www.linkedin.com/company/kicad
> <https://www.linkedin.com/company/kicad>
>