llvm dev - Oct 2015 - Should I worry about test failures in a release?

Going from 3.6 to 3.7 would almost certainly break binary compatibility
between .bc files. You may be able to get away with it for some particular
use-cases (but in that case, it's by luck, not by design).

I'm not enough "part of the community" to say if there are rules
about what
can and can't change between certain levels of releases, but my general
understanding is that "as long as the change is good, it goes in"
[aside
from changes for example between 3.7.0 and 3.7.1, where there is a
guarantee that, modulo actual bugs or undefined behaviour, the two releases
are compatible].

I try to track "trunk" by updating every two-four weeks, and once
every few
of those updates, I need to make changes to my compiler project. Of course,
how many and what kind of changes will depend on what features of LLVM your
project is using. There are some parts of LLVM that are very stable, there
are others with more changes - but all appear to potentially change from my
experience.

The "not guarantee for compatibility between releases" is a good and a
bad
thing, where the bad part is the obvious extra work when something changes,
and the good part is that "things can be changed". I've worked
on/with
projects that have very strict rules of compatibility, where changes to ABI
and API are very difficult to make and everything has to be motivated,
debated, change-controlled and finally agreed with "customers" [in
quotes
as it's often some group within the overall company, but outside your own
group]. This approach makes for slow and often complex changes to "work
around" the fact that you can't actually make the change you want.
It's a
right pain to work with such systems too, even if it may seem like a good
idea at times. Most importantly, it is often harming innovation and
improvements, because of the bureaucracy involved in making changes.

--
Mats

On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thanks, that answered all questions.
>
> One last detail: What's a major version? 3.8 or 4.0?
>
> Regards,
> Jo
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/49771d21/attachment.html>

On 13 October 2015 at 12:56, mats petersson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I've worked on/with
> projects that have very strict rules of compatibility, where changes to ABI
> and API are very difficult to make and everything has to be motivated,
> debated, change-controlled and finally agreed with "customers"
This is more pertinent to low-level *stable* libraries, where
innovation happens elsewhere. :)

In LLVM we worry more about some parts (like the C-API) than others
(like the pass manager), depending on how much *external* code is
likely to change.

But IR compatibility is one of the most public APIs we have and that
changes considerably between releases. AFAIK, there isn't any concern
in keeping it backwards compatible between all 3.x releases. That
surprises a lot of people. :)

Maybe, by 4.x we'll have more stability and new IR features could be a
reason to move to 5.x. But we've been there before, and have chosen
not to do it that way.

cheers,
--renato

Am 13.10.2015 um 13:56 schrieb mats petersson:
> Going from 3.6 to 3.7 would almost certainly break binary compatibility
> between .bc files. You may be able to get away with it for some particular
> use-cases (but in that case, it's by luck, not by design).
>
> I'm not enough "part of the community" to say if there are
rules about what
> can and can't change between certain levels of releases, but my general
> understanding is that "as long as the change is good, it goes in"
[aside
> from changes for example between 3.7.0 and 3.7.1, where there is a
> guarantee that, modulo actual bugs or undefined behaviour, the two releases
> are compatible].
>
> I try to track "trunk" by updating every two-four weeks, and once
every few
> of those updates, I need to make changes to my compiler project. Of course,
> how many and what kind of changes will depend on what features of LLVM your
> project is using. There are some parts of LLVM that are very stable, there
> are others with more changes - but all appear to potentially change from my
> experience.
Thanks, that's very useful feedback.
> The "not guarantee for compatibility between releases" is a good
and a bad
> thing, where the bad part is the obvious extra work when something changes,
> and the good part is that "things can be changed". I've
worked on/with
> projects that have very strict rules of compatibility, where changes to ABI
> and API are very difficult to make and everything has to be motivated,
> debated, change-controlled and finally agreed with "customers"
[in quotes
> as it's often some group within the overall company, but outside your
own
> group]. This approach makes for slow and often complex changes to
"work
> around" the fact that you can't actually make the change you want.
It's a
> right pain to work with such systems too, even if it may seem like a good
> idea at times. Most importantly, it is often harming innovation and
> improvements, because of the bureaucracy involved in making changes.
Heh, I know. One style is a PITA for the infrastructure devs, the other 
is a PITA for the infrastructure users, and then we have a spectrum 
in-between.
I have yet to see a working solution for that.

Regards,
Jo

And outlook still strips llvm-dev sometimes when replying-to-all (didn’t we
already get rid of that problem?)
Argh.

From: Kuperstein, Michael M
Sent: Tuesday, October 13, 2015 15:44
To: 'mats petersson'; Joachim Durchholz
Subject: RE: [llvm-dev] Should I worry about test failures in a release?

As far as I know, the consensus was that all 3.x versions should retain backward
compatibility for bitcode.

So, 3.7 should be able to consume bitcode (but not text IR) produced by any
earlier 3.x. When 4.0 rolls around, all bets are off.
Note that “consume” here is a not as strong a guarantee as it may sound, since
metadata may be stripped off. Debug metadata almost certainly will be.

Michael

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of mats
petersson via llvm-dev
Sent: Tuesday, October 13, 2015 14:57
To: Joachim Durchholz
Cc: LLVM Dev
Subject: Re: [llvm-dev] Should I worry about test failures in a release?

Going from 3.6 to 3.7 would almost certainly break binary compatibility between
.bc files. You may be able to get away with it for some particular use-cases
(but in that case, it's by luck, not by design).
I'm not enough "part of the community" to say if there are rules
about what can and can't change between certain levels of releases, but my
general understanding is that "as long as the change is good, it goes
in" [aside from changes for example between 3.7.0 and 3.7.1, where there is
a guarantee that, modulo actual bugs or undefined behaviour, the two releases
are compatible].
I try to track "trunk" by updating every two-four weeks, and once
every few of those updates, I need to make changes to my compiler project. Of
course, how many and what kind of changes will depend on what features of LLVM
your project is using. There are some parts of LLVM that are very stable, there
are others with more changes - but all appear to potentially change from my
experience.

The "not guarantee for compatibility between releases" is a good and a
bad thing, where the bad part is the obvious extra work when something changes,
and the good part is that "things can be changed". I've worked
on/with projects that have very strict rules of compatibility, where changes to
ABI and API are very difficult to make and everything has to be motivated,
debated, change-controlled and finally agreed with "customers" [in
quotes as it's often some group within the overall company, but outside your
own group]. This approach makes for slow and often complex changes to "work
around" the fact that you can't actually make the change you want.
It's a right pain to work with such systems too, even if it may seem like a
good idea at times. Most importantly, it is often harming innovation and
improvements, because of the bureaucracy involved in making changes.

--
Mats

On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Thanks, that answered all questions.

One last detail: What's a major version? 3.8 or 4.0?

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/2ab2bf16/attachment-0001.html>

On 13 October 2015 at 13:45, Kuperstein, Michael M via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> As far as I know, the consensus was that all 3.x versions should retain
> backward compatibility for bitcode.
Emphasis on "should". :)

I don't think we have enough tests to make sure we don't break that
promise, precisely because it's important, but not crucial.

> So, 3.7 should be able to consume bitcode (but not text IR) produced by any
> earlier 3.x. When 4.0 rolls around, all bets are off.
And not the other way around, either.

> Note that “consume” here is a not as strong a guarantee as it may sound,
> since metadata may be stripped off. Debug metadata almost certainly will
be.
Yup.

--renato

Sadly not. I've sent myself a large number of emails via hand-typed SMTP to
figure out the cause of the problem and IIRC it's a bug in the order changes
are made to the recipient list. It seems Outlook builds a recipient list,
removes duplicates, and then swaps the From for the Reply-To. One copy of
llvm-dev (from the CC) gets lost in the process. Putting llvm-dev in
'To' rather than 'CC' seems to work around it.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Kuperstein, Michael M via llvm-dev
Sent: 13 October 2015 13:46
To: mats petersson; Joachim Durchholz
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Should I worry about test failures in a release?

And outlook still strips llvm-dev sometimes when replying-to-all (didn’t we
already get rid of that problem?)
Argh.

From: Kuperstein, Michael M
Sent: Tuesday, October 13, 2015 15:44
To: 'mats petersson'; Joachim Durchholz
Subject: RE: [llvm-dev] Should I worry about test failures in a release?

As far as I know, the consensus was that all 3.x versions should retain backward
compatibility for bitcode.

So, 3.7 should be able to consume bitcode (but not text IR) produced by any
earlier 3.x. When 4.0 rolls around, all bets are off.
Note that “consume” here is a not as strong a guarantee as it may sound, since
metadata may be stripped off. Debug metadata almost certainly will be.

Michael

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of mats
petersson via llvm-dev
Sent: Tuesday, October 13, 2015 14:57
To: Joachim Durchholz
Cc: LLVM Dev
Subject: Re: [llvm-dev] Should I worry about test failures in a release?

Going from 3.6 to 3.7 would almost certainly break binary compatibility between
.bc files. You may be able to get away with it for some particular use-cases
(but in that case, it's by luck, not by design).
I'm not enough "part of the community" to say if there are rules
about what can and can't change between certain levels of releases, but my
general understanding is that "as long as the change is good, it goes
in" [aside from changes for example between 3.7.0 and 3.7.1, where there is
a guarantee that, modulo actual bugs or undefined behaviour, the two releases
are compatible].
I try to track "trunk" by updating every two-four weeks, and once
every few of those updates, I need to make changes to my compiler project. Of
course, how many and what kind of changes will depend on what features of LLVM
your project is using. There are some parts of LLVM that are very stable, there
are others with more changes - but all appear to potentially change from my
experience.

The "not guarantee for compatibility between releases" is a good and a
bad thing, where the bad part is the obvious extra work when something changes,
and the good part is that "things can be changed". I've worked
on/with projects that have very strict rules of compatibility, where changes to
ABI and API are very difficult to make and everything has to be motivated,
debated, change-controlled and finally agreed with "customers" [in
quotes as it's often some group within the overall company, but outside your
own group]. This approach makes for slow and often complex changes to "work
around" the fact that you can't actually make the change you want.
It's a right pain to work with such systems too, even if it may seem like a
good idea at times. Most importantly, it is often harming innovation and
improvements, because of the bureaucracy involved in making changes.

--
Mats

On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Thanks, that answered all questions.

One last detail: What's a major version? 3.8 or 4.0?

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/bd1376eb/attachment.html>