minutes of ESC call ...

[Lionel Elie Mamane]

On Fri, Mar 11, 2016 at 07:30:54AM +0100, David Ostrovsky wrote:
> On Fri, 2016-03-11 at 06:45 +0100, Lionel Elie Mamane wrote:
> > On Thu, Mar 10, 2016 at 07:28:58PM +0100, David Ostrovsky wrote:
> > > On Thu Mar 10 16:40:50 UTC 2016, Michael Meeks wrote:
> 
> [...]
> 
> > > >    + decision needed: (Norbert)
> > > >        + effort to support VS 2015
> > > >        + not eager to turn it off.
> > > > AI:        => regret; disable for now for CI (Norbert)
> > 
> > > (...) the FB devs rejected support for the new toolchain
> > > (C++14/C++17) for the next 10 years (at least) because they need
> > > the
> > > compatibility with WinXP (see the thread from their ML I mentioned
> > > in my previous mail).
> > 
> > I read that thread and I didn't see a rejection of compatibility with
> > a new toolchain. I saw a requirement for compatibility with an old
> > toolchain. If they intend (and do test it at least "for every
> > release") to:
> > 
> >  * be compatible with MSVC2013
> >  * build their binaries with MSVC2013
> >  * AND be compatible with

> Can you point me to this statement in this thread?

That was within the scope of an "if". We don't know if they intend
this to be the case. We need to clarify this. I will ask them.

>> MSVC${LAST_VERSION_WITHIN_A_REASONABLE_TIMEFRAME}

> You are missing one subtle delay here:

> TIME_NEEDED_THAT_A_HACKER_SHOWS_UP_AND_BUMP_CURRENT_FB_VERSION_TO_THE_R
> ECENT_ONE_THAT_SUPPORTS
> MSVC${LAST_VERSION_WITHIN_A_REASONABLE_TIMEFRAME}

This is true for any external written in any compiled (or even
interpreted) language that doesn't have perfect ascending
compatibility (so any language?)...

>> then AFAICS we don't have a problem.

> I see it differently. Just in case, we dropped MSVC 2013 and the
> LAST_VERSION_WITHIN_A_REASONABLE_TIMEFRAME = 10 years,

No, more like 1 year.

> 1/ How is LO 6,7,8,9,10, ... going to be released, after support for
> MSVC 2013 was discontinued on master?

?

> With disabled FB? Also disable it in release build on Mac (it's failing
> on recent toolchain there too)? Is this our vision for the (default)
> embedded database, to be buildable and shipped on only one platform for
> years (from major 3): linux? Really?

No, that can work only if Firebird compiles with an MSVC, clang
(and gcc I suppose) that suits us.


> 2/ For all this time, that FB is not buildable on some platform(s),
> but still in the tree

We will not let it like that for the timeframe that you mention.

> Can we try to answer my questions 1/ and 2/ above in next ESC
> meeting?

If/when we have enough new information that a discussion at the ESC
makes sense, would you like to participate at that ESC meeting?

-- 
Lionel