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

On Tue, Jun 28, 2016 at 12:55 PM, Chandler Carruth via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Tue, Jun 28, 2016 at 12:45 PM Rafael Espíndola <
> openmp-dev at lists.llvm.org> wrote:
>
>> > I don't think this is as obvious as you might think it is. We
can
>> happily
>> > drop the "major version equals bitcode compatibility"
implicit promise
>> if we
>> > want, but it's been there for a while and will need some
messaging as
>> to the
>> > actual promises here and what we'll do to fulfill and what we
mean when
>> we
>> > want to change it (will we actually rev the version? not?). I
think
>> Hans's
>> > idea for the release is fine and then will let us argue it as much
as
>> we'd
>> > like on llvm-dev until we get a proposal that people are happy
with.
>>
>> The promise just says that 4.0 *will* read 3.X and 4.1 might.
>>
>
> Yes, but while you have read it and interpreted it precisely, I suspect
> that many people have misinterpreted it and assume that 4.0 will be the
> last release to read 3.X. They may be incorrect, but I think it would still
> be worth considering them and working to communicate this effectively.
>
> Essentially, what Eric said: it may be accurate, but it isn't
*obvious*,
> at least not to everyone.
>
>
>>
>> I think I agree with Chris with 3.10 being the worst possible outcome.
>>
>
> I'd be interested to understand why you or Chris thing 3.10 is the
worst
> possible outcome.
>
Personally: I think it would be a bad outcome, because if we go to 3.10, I
do not see when we would ever transition to 4.0. What change would be
"large enough" to classify as a new major version of all of LLVM?
Given
that we are (presumably) going to have a "sliding window" support
story for
LLVM IR changes, and even LLVM IR changes are irrelevant to a significant
number of LLVM subprojects (all of which share the same versioning scheme),
it's not clear to me what would justify this.

Chris has said it is because he thinks we'll never change the "3",
but I
> don't understand why 3.10 is worse than 3.9 was in that respect. I
happen
> to agree that we'll never change the "3", but I don't
think this makes 3.10
> a particularly bad choice.
>
We've historically gone from x.9 to x+1.0, so this sets precedent, and we
seem to have the energy and motivation to discuss and possibly change our
version numbering scheme right now. For me, it's just a question of "if
not
now, then when?".

I'm seeing pretty much zero support for continuing to have a
major/minor
> split. As such, I pretty strongly suggest that as a community we move to a
> single integer that increments every (time based) release, and a .N that
> increments with every patch release off of that branch. GCC and numerous
> other projects work this way.
>
> I actually don't care at all what the number is: 4 or 40 seem fine.
>
> If 4 seems too confusing, and 40 seems too extreme, how about 10.
> Seriously. It seems exactly as good as any other integer to start counting
> rationally, and won't confuse people by looking like a 4.0 release.
>
I think going to 10 or 40 is likely to be confusing, because there'll be
two different ways to refer to the same version (people will say 3.10 when
referring to version 10, or 38 when referring to version 3.8,
respectively). This happened to Java in the version 1.6 / version 6
numbering transition.

In order to preserve numbering continuity and minimize confusion, if we go
from three-component versions (major.minor.patch) to two-component versions
(major.patch), I would suggest we go from x.y.z to x+1.0. (This is also
consistent with how GCC handled the transition.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/fbb766cb/attachment.html>

> On 2016-Jun-28, at 13:17, Richard Smith via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
> 
>>> I think I agree with Chris with 3.10 being the worst possible
outcome.
>> 
>> I'd be interested to understand why you or Chris thing 3.10 is the
worst possible outcome.
> 
> Personally: I think it would be a bad outcome, because if we go to 3.10, I
do not see when we would ever transition to 4.0. What change would be
"large enough" to classify as a new major version of all of LLVM?
Given that we are (presumably) going to have a "sliding window"
support story for LLVM IR changes, and even LLVM IR changes are irrelevant to a
significant number of LLVM subprojects (all of which share the same versioning
scheme), it's not clear to me what would justify this.
> 
>> Chris has said it is because he thinks we'll never change the
"3", but I don't understand why 3.10 is worse than 3.9 was in that
respect. I happen to agree that we'll never change the "3", but I
don't think this makes 3.10 a particularly bad choice.
> 
> We've historically gone from x.9 to x+1.0, so this sets precedent, and
we seem to have the energy and motivation to discuss and possibly change our
version numbering scheme right now. For me, it's just a question of "if
not now, then when?".
> 
>> I'm seeing pretty much zero support for continuing to have a
major/minor split. As such, I pretty strongly suggest that as a community we
move to a single integer that increments every (time based) release, and a .N
that increments with every patch release off of that branch. GCC and numerous
other projects work this way.
>> 
>> I actually don't care at all what the number is: 4 or 40 seem fine.
>> 
>> If 4 seems too confusing, and 40 seems too extreme, how about 10.
Seriously. It seems exactly as good as any other integer to start counting
rationally, and won't confuse people by looking like a 4.0 release.
> 
> I think going to 10 or 40 is likely to be confusing, because there'll
be two different ways to refer to the same version (people will say 3.10 when
referring to version 10, or 38 when referring to version 3.8, respectively).
This happened to Java in the version 1.6 / version 6 numbering transition.
> 
> In order to preserve numbering continuity and minimize confusion, if we go
from three-component versions (major.minor.patch) to two-component versions
(major.patch), I would suggest we go from x.y.z to x+1.0. (This is also
consistent with how GCC handled the transition.)
I agree with Richard.  While I don't have a strong opinion about 3.10.x vs.
4.x vs. 4.0.x (assuming we document our *actual* bitcode compatibility promise),
I think both 10.x and 40.x are actively confusing.

On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
>> If 4 seems too confusing, and 40 seems too extreme, how about 10.
>> Seriously. It seems exactly as good as any other integer to start
counting
>> rationally, and won't confuse people by looking like a 4.0 release.
>
>
> I think going to 10 or 40 is likely to be confusing, because there'll
be two
> different ways to refer to the same version (people will say 3.10 when
> referring to version 10, or 38 when referring to version 3.8,
respectively).
> This happened to Java in the version 1.6 / version 6 numbering transition.
>
> In order to preserve numbering continuity and minimize confusion, if we go
> from three-component versions (major.minor.patch) to two-component versions
> (major.patch), I would suggest we go from x.y.z to x+1.0. (This is also
> consistent with how GCC handled the transition.)
I haven't followed how this worked out for GCC, but I worry that if we
go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
get confused when we ship 4.1 as a "dot" release instead of a major
release like we've used to.

There's also the question of how to practically go from a 3-tuple to a
2-tuple. Should we drop it from the version string and dir names in
Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I see
GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to
do it?

Cheers,
Hans

----- Original Message -----
> From: "Hans Wennborg via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Richard Smith" <richard at metafoo.co.uk>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Chris
Lattner" <sabre at nondot.org>, "openmp-dev
> (openmp-dev at lists.llvm.org)" <openmp-dev at lists.llvm.org>,
"LLDB" <lldb-dev at lists.llvm.org>, "cfe-dev"
> <cfe-dev at lists.llvm.org>, "David Blaikie" <blaikie at
google.com>, "Paul Robinson" <Paul_Robinson at
playstation.sony.com>
> Sent: Tuesday, June 28, 2016 3:38:06 PM
> Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] [Openmp-dev] What version
comes after 3.9? (Was: [3.9 Release] Release
> plan and call for testers)
> 
> On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> >> If 4 seems too confusing, and 40 seems too extreme, how about 10.
> >> Seriously. It seems exactly as good as any other integer to start
> >> counting
> >> rationally, and won't confuse people by looking like a 4.0
> >> release.
> >
> >
> > I think going to 10 or 40 is likely to be confusing, because
> > there'll be two
> > different ways to refer to the same version (people will say 3.10
> > when
> > referring to version 10, or 38 when referring to version 3.8,
> > respectively).
> > This happened to Java in the version 1.6 / version 6 numbering
> > transition.
> >
> > In order to preserve numbering continuity and minimize confusion,
> > if we go
> > from three-component versions (major.minor.patch) to two-component
> > versions
> > (major.patch), I would suggest we go from x.y.z to x+1.0. (This is
> > also
> > consistent with how GCC handled the transition.)
> 
> I haven't followed how this worked out for GCC, but I worry that if
> we
> go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
> get confused when we ship 4.1 as a "dot" release instead of a
major
> release like we've used to.
> 
> There's also the question of how to practically go from a 3-tuple to
> a
> 2-tuple. Should we drop it from the version string and dir names in
> Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I
> see
> GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to
> do it?
I think that the directory names should match the version string. Both are
user-facing. For the macros, I'd rather set the minor version to 0, since
"patch level" really is the correct descriptive name for the final
digit in our stable releases.

 -Hal
> 
> Cheers,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Tue, Jun 28, 2016 at 4:38 PM Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

I haven't followed how this worked out for GCC, but I worry that if
we
> go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
> get confused when we ship 4.1 as a "dot" release instead of a
major
> release like we've used to.
>
GCC does one major release a year.  That release gets a new major number.
Subsequent releases during that year get a minor number (
https://gcc.gnu.org/develop.html#timeline)

Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/078f7f14/attachment.html>

> On Jun 28, 2016, at 4:26 PM, Duncan P. N. Exon Smith via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 
> 
>> On 2016-Jun-28, at 13:17, Richard Smith via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
>> 
>>>> I think I agree with Chris with 3.10 being the worst possible
outcome.
>>> 
>>> I'd be interested to understand why you or Chris thing 3.10 is
the worst possible outcome.
>> 
>> Personally: I think it would be a bad outcome, because if we go to
3.10, I do not see when we would ever transition to 4.0. What change would be
"large enough" to classify as a new major version of all of LLVM?
Given that we are (presumably) going to have a "sliding window"
support story for LLVM IR changes, and even LLVM IR changes are irrelevant to a
significant number of LLVM subprojects (all of which share the same versioning
scheme), it's not clear to me what would justify this.
>> 
>>> Chris has said it is because he thinks we'll never change the
"3", but I don't understand why 3.10 is worse than 3.9 was in that
respect. I happen to agree that we'll never change the "3", but I
don't think this makes 3.10 a particularly bad choice.
>> 
>> We've historically gone from x.9 to x+1.0, so this sets precedent,
and we seem to have the energy and motivation to discuss and possibly change our
version numbering scheme right now. For me, it's just a question of "if
not now, then when?".
>> 
>>> I'm seeing pretty much zero support for continuing to have a
major/minor split. As such, I pretty strongly suggest that as a community we
move to a single integer that increments every (time based) release, and a .N
that increments with every patch release off of that branch. GCC and numerous
other projects work this way.
>>> 
>>> I actually don't care at all what the number is: 4 or 40 seem
fine.
>>> 
>>> If 4 seems too confusing, and 40 seems too extreme, how about 10.
Seriously. It seems exactly as good as any other integer to start counting
rationally, and won't confuse people by looking like a 4.0 release.
>> 
>> I think going to 10 or 40 is likely to be confusing, because
there'll be two different ways to refer to the same version (people will say
3.10 when referring to version 10, or 38 when referring to version 3.8,
respectively). This happened to Java in the version 1.6 / version 6 numbering
transition.
>> 
>> In order to preserve numbering continuity and minimize confusion, if we
go from three-component versions (major.minor.patch) to two-component versions
(major.patch), I would suggest we go from x.y.z to x+1.0. (This is also
consistent with how GCC handled the transition.)
> 
> I agree with Richard.  While I don't have a strong opinion about 3.10.x
vs. 4.x vs. 4.0.x (assuming we document our *actual* bitcode compatibility
promise), I think both 10.x and 40.x are actively confusing.
I can see an argument for 10.x: let’s just drop the leading "3.” And
continue to number from where we are, i.e. 10.

—
Mehdi