Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

> On Jun 28, 2016, at 8:40 AM, Hans Wennborg  wrote:
> 
>> I continue to think that 3.10 is the least defensible option out there.  We 
>> have a time based release process with no mechanism or attempt to align 
>> behind “big” releases that could bring is to a 4.x number.  You might as 
>> well call the release “10” at this point, since the "3.” will become archaic 
>> legacy that we can’t shed.
>> 
>> Trust me, I’ve seen this happen several times in the past in multiple 
>> different products (both open source and proprietary), and have had success 
>> leading one to a more predictable release number pattern like I’m advocating 
>> for.  This is a problem that we are simply walking into by naming it 3.10, 
>> there is no reason to do that.
>> 
>> I still don’t understand what “confusion” could be caused by going from 3.9 
>> to 4.0.  Could someone please elaborate on what the problem is that needs 
>> solving?  If it is that people don’t understand what is major about the 
>> release, I would say “who cares”?
> 
> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

If that is the confusion, then I suggest that we just document (in the release 
notes) what the supported compatibility range is for any release.  That makes 
it completely unambiguous, and means that we don’t have to make an arbitrary 
policy up front (exactly N years of support!), we can drive it based on the 
cost/benefit involved with making a specific change.

Besides, people “expecting” 4.0 to break compatibility will likely ask about 
it, and be pleasantly surprised :-).  I don’t think that the association of 
major number to bitcode compatibility is actually well known outside the core 
group of folks that hang out on llvm-dev anyway.

I think that there is a reasonable argument to be made for switching to a 
semantic versioning model.  Instead of 3.9, 4.0, 4.1 we would switch to 4.0, 
5.0, 6.0 and then “4.1” would be a patch release.  It appears that jumping to 
40 just freaks too many people out.

-Chris

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Rafael Espíndola via lldb-dev]

> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

It is tied in saying we *can* drop compatibility, not that we will. If
we still support loading 3.0 bitcode when 4.1 ships we just have to
document that. It just given us the flexibility to drop it in 4.2 if
we want.

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Robinson, Paul via lldb-dev]

> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans
> Wennborg
> On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner  wrote:
> > I still don’t understand what “confusion” could be caused by going from
> 3.9 to 4.0.  Could someone please elaborate on what the problem is that
> needs solving?  If it is that people don’t understand what is major about
> the release, I would say “who cares”?
> 
> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.

Somebody proposed a time-based-version bitcode compatibility policy.
IMHO the easiest to remember would be "X.Y supports back to (X-1).Y"
but opinions vary (e.g. 3 years, where my idea would mean 5 years) and
nobody has tried to nail one down.

Of course actually removing an auto-upgrade feature means having to do
the archaeology to figure out when each piece was introduced, and then
how to disentangle it cleanly.  I'm not aware that these things are
identified by version, other than by researching the commit history.
With the old scheme, you'd just rip it all out at 4.1 without having
to worry about when each piece was introduced.  With the time-based
scheme there's a higher barrier to removing the old code.
--paulr

> 
> But if you really insist on 4.0 rather than 3.10, I will of course honour
> that.
> 
> Cheers,
> Hans

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner  wrote:
> On Jun 27, 2016, at 4:57 PM, Hans Wennborg  wrote:
>>> Eh, if we're switching to a completely unrelated versioning scheme, it
>>> doesn't seem completely unreasonable.
>>>
>>> We could also count how many time-based releases we have had and use that...
>>>
>>> :: shrug ::
>>>
>>> I think counting from 4 or counting from 40 are all fine ways to number
>>> releases.
>>
>>
>> This is what I arrived at after my weekend of thinking about version numbers:
>>
>> While there's been many good arguments for doing something different
>> and revising our versioning scheme, I really just want to bump the
>> number with the least amount of work possible.
>>
>> When we branch for 3.9, my plan is to bump trunk to 3.10, and then
>> focus my attention on getting 3.9 into a good state and shipping it.
>>
>> After the branch, if someone wants to promote trunk to 4.0 because of
>> a feature, or because the 3-series is "done", go ahead. If someone
>> wants to spearhead getting us onto a scheme where we increment major
>> for each release, that's fine too, but I'm not going to drive it.
>>
>> Thanks everyone for participating in the discussion. Hopefully this
>> result is not too disappointing.
>
> I continue to think that 3.10 is the least defensible option out there.  We 
> have a time based release process with no mechanism or attempt to align 
> behind “big” releases that could bring is to a 4.x number.  You might as well 
> call the release “10” at this point, since the "3.” will become archaic 
> legacy that we can’t shed.
>
> Trust me, I’ve seen this happen several times in the past in multiple 
> different products (both open source and proprietary), and have had success 
> leading one to a more predictable release number pattern like I’m advocating 
> for.  This is a problem that we are simply walking into by naming it 3.10, 
> there is no reason to do that.
>
> I still don’t understand what “confusion” could be caused by going from 3.9 
> to 4.0.  Could someone please elaborate on what the problem is that needs 
> solving?  If it is that people don’t understand what is major about the 
> release, I would say “who cares”?

I think the main issue (besides users asking what's the big change in
4.0, which I agree is not a big problem) is that the bitcode
compatibility policy is tied to the major version number.

But if you really insist on 4.0 rather than 3.10, I will of course honour that.

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Jim Rowan via lldb-dev]

On Jun 27, 2016, at 9:57 PM, Chris Lattner via llvm-dev 
 wrote:

> 
> I continue to think that 3.10 is the least defensible option out there.  

I agree, given that there isn’t a concurrent agreement that we want to define 
and conform to a semantic versioning scheme — and that agreement not only 
hasn’t happened but seems quite unlikely.

> We have a time based release process with no mechanism or attempt to align 
> behind “big” releases that could bring is to a 4.x number.  You might as well 
> call the release “10” at this point, since the "3.” will become archaic 
> legacy that we can’t shed.

Yes, that does seem likely.

> I still don’t understand what “confusion” could be caused by going from 3.9 
> to 4.0.  

I believe it is rooted in some folks expectation that the versions follow the 
semantic versioning paradigm.A numbering scheme that more directly 
indicated “time-based”, and that had less of a chance of being interpreted as 
conveying semantic content would indeed be less “confusing”.

> Could someone please elaborate on what the problem is that needs solving?  

I think the real point, mostly unspoken, is this expectation for semantic 
versioning.   Since that isn’t directly being discussed, I also don’t see a 
problem that needs solving.

Jim Rowan
j...@codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by 
the Linux Foundation



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

On Jun 27, 2016, at 4:57 PM, Hans Wennborg  wrote:
>> Eh, if we're switching to a completely unrelated versioning scheme, it
>> doesn't seem completely unreasonable.
>> 
>> We could also count how many time-based releases we have had and use that...
>> 
>> :: shrug ::
>> 
>> I think counting from 4 or counting from 40 are all fine ways to number
>> releases.
> 
> 
> This is what I arrived at after my weekend of thinking about version numbers:
> 
> While there's been many good arguments for doing something different
> and revising our versioning scheme, I really just want to bump the
> number with the least amount of work possible.
> 
> When we branch for 3.9, my plan is to bump trunk to 3.10, and then
> focus my attention on getting 3.9 into a good state and shipping it.
> 
> After the branch, if someone wants to promote trunk to 4.0 because of
> a feature, or because the 3-series is "done", go ahead. If someone
> wants to spearhead getting us onto a scheme where we increment major
> for each release, that's fine too, but I'm not going to drive it.
> 
> Thanks everyone for participating in the discussion. Hopefully this
> result is not too disappointing.

I continue to think that 3.10 is the least defensible option out there.  We 
have a time based release process with no mechanism or attempt to align behind 
“big” releases that could bring is to a 4.x number.  You might as well call the 
release “10” at this point, since the "3.” will become archaic legacy that we 
can’t shed.

Trust me, I’ve seen this happen several times in the past in multiple different 
products (both open source and proprietary), and have had success leading one 
to a more predictable release number pattern like I’m advocating for.  This is 
a problem that we are simply walking into by naming it 3.10, there is no reason 
to do that.

I still don’t understand what “confusion” could be caused by going from 3.9 to 
4.0.  Could someone please elaborate on what the problem is that needs solving? 
 If it is that people don’t understand what is major about the release, I would 
say “who cares”?  

-Chris
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 3:40 PM, Chandler Carruth  wrote:
> On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev
>  wrote:
>>
>> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
>> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
>> >  wrote:
>> >> That's what concerns me about going to the scheme Richard and Rafael
>> >> suggested, of bumping the major version each time: we'd release 4.0,
>> >> and would Tom's dot-release then be 4.1? That would be confusing to
>> >> those who are used to our current scheme. Chris suggested going
>> >> straight to 40 to avoid this, but that also seems a bit extreme.
>> >
>> > Extreme how?  What do you mean by “extreme"?
>>
>> Sorry, that might have been a poor choice of wording.
>>
>> I just meant that change seems to have a much greater magnitude than
>> the other proposals. I realize that's sort of the point, to make the
>> change clear to users, but instinctively it feels wrong -- like
>> cheating by skipping 36 versions :-)
>
>
> Eh, if we're switching to a completely unrelated versioning scheme, it
> doesn't seem completely unreasonable.
>
> We could also count how many time-based releases we have had and use that...
>
> :: shrug ::
>
> I think counting from 4 or counting from 40 are all fine ways to number
> releases.


This is what I arrived at after my weekend of thinking about version numbers:

While there's been many good arguments for doing something different
and revising our versioning scheme, I really just want to bump the
number with the least amount of work possible.

When we branch for 3.9, my plan is to bump trunk to 3.10, and then
focus my attention on getting 3.9 into a good state and shipping it.

After the branch, if someone wants to promote trunk to 4.0 because of
a feature, or because the 3-series is "done", go ahead. If someone
wants to spearhead getting us onto a scheme where we increment major
for each release, that's fine too, but I'm not going to drive it.

Thanks everyone for participating in the discussion. Hopefully this
result is not too disappointing.

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
> On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev 
>  wrote:
>> That's what concerns me about going to the scheme Richard and Rafael
>> suggested, of bumping the major version each time: we'd release 4.0,
>> and would Tom's dot-release then be 4.1? That would be confusing to
>> those who are used to our current scheme. Chris suggested going
>> straight to 40 to avoid this, but that also seems a bit extreme.
>
> Extreme how?  What do you mean by “extreme"?

Sorry, that might have been a poor choice of wording.

I just meant that change seems to have a much greater magnitude than
the other proposals. I realize that's sort of the point, to make the
change clear to users, but instinctively it feels wrong -- like
cheating by skipping 36 versions :-)

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev 
 wrote:
> That's what concerns me about going to the scheme Richard and Rafael
> suggested, of bumping the major version each time: we'd release 4.0,
> and would Tom's dot-release then be 4.1? That would be confusing to
> those who are used to our current scheme. Chris suggested going
> straight to 40 to avoid this, but that also seems a bit extreme.

Extreme how?  What do you mean by “extreme"?

-Chris
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chris Lattner via lldb-dev]

> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev 
>  wrote:
> 
> On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev 
> > wrote:
>> I think that this is the right approach, and we happen to have a natural 
>> forcing function here: opaque pointer types. I think we should increment the 
>> major version number when opaque pointer types are here, as it will be a 
>> major breaking change, and then we'll have a version 4.0. Until then, unless 
>> something else breaking comes up, 3.10 sounds fine to me.
>> 
>> We're talking about version numbers for the entire LLVM project here, which 
>> encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is 
>> utterly irrelevant. I'm not convinced that tying version numbers to 
>> backwards-incompatible changes to IR is reasonable any more, and it doesn't 
>> seem hard to explicitly document the oldest version with which we are 
>> compatible (in fact, we need to do that regardless, whether we say it's "the 
>> same major version" or "everything since 3.0" or whatever else).
>> 
>> Given that our releases are time-based rather than feature-based, I don't 
>> see a distinct major / minor version being anything other than arbitrary, so 
>> I'd suggest we take 4.0 as our next release, 4.1 as the first patch release 
>> on that, 5.0 as the next release after that, and so on.
> 
> I completely agree with Richard here.  “Breaking of IR compatibility” was an 
> interesting metric for older and less mature versions of LLVM.  We can solve 
> the same sort of challenge (the desire to eject old autoupgrade code) by 
> having a sliding window of versions supported (e.g. version 4.5 supports back 
> to version 3.6).

Let me clarify.  What I’m trying to say is that:

a) LLVM has a time-based release cycle, not a schedule-based one.  As such, a 
simple and predictable version number makes sense.
b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its 
centrality to the project in some ways.
c) I think that it makes sense to keep adding 0.1 to each major release going 
forward well into the future.

On the topic of the pointer changes proposed, I really don’t think the 
community is served by waiting for that.  The supposition seems to be that we’d 
land it *without* upgrade support, but then bump the major version number to 
indicate this.  If that’s the proposal, I think that doing such a thing would 
be disastrous for the LLVM community as a whole: we need to have at least some 
sliding window of support for older formats.

-Chris

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Robinson, Paul via lldb-dev]

| Note that 81 > 8, so those examples would still work.
Right, but also 81 > 9 so that example would not work, if you don't understand 
how the project does version numbers.

As different projects work by different rules, I guess the interpretation of 
version numbers by other tools would have to be project-dependent.  So, all 
that matters is that LLVM asserts what rule it will follow (and then actually 
follows it!).  The Wikipedia quote seems to suggest that whole-number tuples 
(e.g.: 3.8, 3.9, 3.10) are more common than decimal strings (e.g.: 3.8, 3.81, 
3.9) and so we should not be afraid to use tuples.
--paulr

From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of Adrian 
McCarthy via llvm-dev
Sent: Thursday, June 16, 2016 10:03 AM
To: Bruce Hoult
Cc: llvm-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev; cfe-dev; 
Robinson, Paul
Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] What version comes after 3.9? 
(Was: [3.9 Release] Release plan and call for testers)

>Version numbers aren't strings, and they aren't floating point numbers, they 
>are a series of integers separated by dots. I can't think of a project where 
>interpreting version numbers that way won't work.

TeX (asymptotically approaches pi), METAFONT (asymptotically approaches e), 
Opera (decimal number).

Sayeth 
Wikipedia:
Most free and open-source software packages, including MediaWiki, treat 
versions as a series of individual numbers, separated by periods, with a 
progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, 
and so on. On the other hand, some software packages identify releases by 
decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc.

Note that 81 > 8, so those examples would still work.  But 3.10 is easy to 
misinterpret as 3.1.

On Thu, Jun 16, 2016 at 2:46 AM, Bruce Hoult via lldb-dev 
> wrote:
Bug in cmake (or more likely the makefile?), pure and simple. Version numbers 
aren't strings, and they aren't floating point numbers, they are a series of 
integers separated by dots. I can't think of a project where interpreting 
version numbers that way won't work.

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Adrian McCarthy via lldb-dev]

>Version numbers aren't strings, and they aren't floating point numbers,
they are a series of integers separated by dots. I can't think of a project
where interpreting version numbers that way won't work.

TeX (asymptotically approaches pi), METAFONT (asymptotically approaches e),
Opera (decimal number).

Sayeth Wikipedia
:

> Most free and open-source software packages, including MediaWiki, treat
> versions as a series of individual numbers, separated by periods, with a
> progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1,
> 1.11.2, and so on. On the other hand, some software packages identify
> releases by decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc.


Note that 81 > 8, so those examples would still work.  But 3.10 is easy to
misinterpret as 3.1.

On Thu, Jun 16, 2016 at 2:46 AM, Bruce Hoult via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Bug in cmake (or more likely the makefile?), pure and simple. Version
> numbers aren't strings, and they aren't floating point numbers, they are a
> series of integers separated by dots. I can't think of a project where
> interpreting version numbers that way won't work.
>
> On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> Hello there,
>>
>> First, I would like to say that I don't have any strong opinions on this
>> matter: as mostly an user of LLVM, my basic concern is for me to be able to
>> identify which version is the newest and configure it as easily as
>> possible. That being said, I have a question about LLVM's versioning
>> strategy: is it possible for other tools (including the ones LLVM depend
>> on) to become broke or annoyingly buggy just because a bad versioning
>> scheme was put in place?
>>
>> Just to give some context to this question, I've been using OS X for a
>> while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
>> X 10.10. Not at first, no: I didn't realize this would have any impact on
>> my workspace until I had to compile some code, and CMake kept stopping just
>> because it recognized that I was using an older version of the OS (emphasis
>> on *older*). It is funny when you realize that 10.10 should actually be
>> interpreted as less than 10.9, and CMake was falling for it, which was a
>> wrong behavior of the tool, I admit, but the weird OS versioning scheme was
>> the main cause of this issue. Of course this problem can be easily arranged
>> by setting up some extra environment variables to tell CMake to target OS X
>> 10.9 instead, but that was a very irritating behavior and only happened
>> because a bunch of people (from CMake, and, then, from OS X's development
>> team) thought comparing versions directly shouldn't be a problem. Besides,
>> every one of these small details end up being some extra steps a new user
>> need to follow to be able to use a tool, some of which could be easily
>> avoided.
>>
>> I confess I didn't look into this matter after that, and still today, on
>> OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X --
>> thus, I don't know if this bug was fixed or not. However, as I'm starting
>> to see a very similar pattern happening with LLVM on this thread, and I
>> thought I could contribute with the discussion: did someone check if naming
>> the next version "3.10" would have any impact on a production system?
>>
>>
>> --
>> Cristianno Martins
>> 
>>
>> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
>>> cfe-...@lists.llvm.org> wrote:
>>>


 On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
 cfe-...@lists.llvm.org> wrote:

> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> - Original Message -
>> > From: "Hans Wennborg via cfe-dev" 
>> > To: "llvm-dev" , "cfe-dev" <
>> cfe-...@lists.llvm.org>, "LLDB Dev" ,
>> > "openmp-dev (openmp-...@lists.llvm.org)" > >
>> > Cc: "r jordans" , "Paul Robinson" <
>> paul_robin...@playstation.sony.com>
>> > Sent: Monday, June 13, 2016 6:54:19 PM
>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9
>> Release] Release plan and call for testers)
>> >
>> > Breaking this out into a separate thread since it's kind of a
>> > separate
>> > issue, and to make sure people see it.
>> >
>> > If you have opinions on this, please chime in. I'd like to collect
>> as
>> > many arguments here as possible to make a good decision. The main
>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>> > surprised by both.
>> >

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Bruce Hoult via lldb-dev]

Bug in cmake (or more likely the makefile?), pure and simple. Version
numbers aren't strings, and they aren't floating point numbers, they are a
series of integers separated by dots. I can't think of a project where
interpreting version numbers that way won't work.

On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hello there,
>
> First, I would like to say that I don't have any strong opinions on this
> matter: as mostly an user of LLVM, my basic concern is for me to be able to
> identify which version is the newest and configure it as easily as
> possible. That being said, I have a question about LLVM's versioning
> strategy: is it possible for other tools (including the ones LLVM depend
> on) to become broke or annoyingly buggy just because a bad versioning
> scheme was put in place?
>
> Just to give some context to this question, I've been using OS X for a
> while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS
> X 10.10. Not at first, no: I didn't realize this would have any impact on
> my workspace until I had to compile some code, and CMake kept stopping just
> because it recognized that I was using an older version of the OS (emphasis
> on *older*). It is funny when you realize that 10.10 should actually be
> interpreted as less than 10.9, and CMake was falling for it, which was a
> wrong behavior of the tool, I admit, but the weird OS versioning scheme was
> the main cause of this issue. Of course this problem can be easily arranged
> by setting up some extra environment variables to tell CMake to target OS X
> 10.9 instead, but that was a very irritating behavior and only happened
> because a bunch of people (from CMake, and, then, from OS X's development
> team) thought comparing versions directly shouldn't be a problem. Besides,
> every one of these small details end up being some extra steps a new user
> need to follow to be able to use a tool, some of which could be easily
> avoided.
>
> I confess I didn't look into this matter after that, and still today, on
> OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X --
> thus, I don't know if this bug was fixed or not. However, as I'm starting
> to see a very similar pattern happening with LLVM on this thread, and I
> thought I could contribute with the discussion: did someone check if naming
> the next version "3.10" would have any impact on a production system?
>
>
> --
> Cristianno Martins
> 
>
> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>>
>>
>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
>>> cfe-...@lists.llvm.org> wrote:
>>>
 On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> - Original Message -
> > From: "Hans Wennborg via cfe-dev" 
> > To: "llvm-dev" , "cfe-dev" <
> cfe-...@lists.llvm.org>, "LLDB Dev" ,
> > "openmp-dev (openmp-...@lists.llvm.org)" 
> > Cc: "r jordans" , "Paul Robinson" <
> paul_robin...@playstation.sony.com>
> > Sent: Monday, June 13, 2016 6:54:19 PM
> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
> Release plan and call for testers)
> >
> > Breaking this out into a separate thread since it's kind of a
> > separate
> > issue, and to make sure people see it.
> >
> > If you have opinions on this, please chime in. I'd like to collect as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> > change?
>
> I think that this is the right approach, and we happen to have a
> natural forcing function here: opaque pointer types. I think we should
> increment the major version number when opaque pointer types are here, as
> it will be a major breaking change, and then we'll have a version 4.0.
> Until then, unless something else breaking comes up, 3.10 sounds fine to 
> me.
>

 +1, complete agreement.

>>>
>>> While I'm not sure opaque