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

> 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.

I think I agree with Chris with 3.10 being the worst possible outcome.
If the "may be compatible" is too confusing lets change it to be time
base or just say that llvm for now can read bitcode of llvm 3.0 or
newer but we might change that in the future.

Cheers,
Rafael

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.

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.


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.

My 2 cents.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/de302056/attachment.html>

On Tue, Jun 28, 2016 at 12:55 PM Chandler Carruth via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> My 2 cents.
>
And just to be explicit, I 100% support the person doing the heroic work to
*make* our releases having the final say in how they are numbered. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/93ad32ea/attachment.html>

>> 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.
So lets fix that. What is your preference of wording? Specially if we
go to a single integer model?
>> 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.
>
> 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.
It makes the "3." look more significant than it is and we will keep
having discussions about what is "major" in the future.
> 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 like this. And that is why I don't like the 3.10. It makes the major
number seem more significant than it looks currently (we avoided
changing it after all).

Cheers,
Rafael

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>

----- Original Message -----
> From: "Chandler Carruth via Openmp-dev" <openmp-dev at
lists.llvm.org>
> To: "Rafael Espíndola" <rafael.espindola at gmail.com>,
"Eric
> Christopher" <echristo at gmail.com>
> 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 2:55:21 PM
> Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] [lldb-dev] What
> version comes after 3.9? (Was: [3.9 Release] Release plan and call
> for testers)
> ...
> 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 that there are good marketing reasons to not be stuck at 3.x for a long
time. People want to use actively-developed software that is neither too young
(i.e. likely immature) nor too old. Thus, while always being on version 3.x is
bad, being on version 50 or 100 also might send the wrong message. Given two
releases per year, I think that starting at 40 is a bad idea, as we'll soon
end up with numbers that look too large (in some subjective sense). Starting at
8 or 10 seems better.

Also, many people are used to the odd/even numbering schemes used by many
projects (i.e. odd is unstable and even is stable), and I've noticed that
some people have an unconscious bias as a result, so we might stay away from odd
numbers for that reason.

-Hal 
> My 2 cents.
> -Chandler
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/1f267876/attachment.html>

On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev <openmp-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.
> 
> Chris has said it is because he thinks we'll never change the "3”,
Yes, that is one reason.
> but I don't understand why 3.10 is worse than 3.9 was in that respect.
Because it breaks from the established pattern we have, and means that we never
get to 4.
> I happen to agree that we'll never change the "3", but I
don't think this makes 3.10 a particularly bad choice.
If you agree that we’ll never change the 3, then you are staying that you
believe it is ok for the version number to be meaningless.  In that case, I
can’t see why you’d object to a policy change.

I believe that the version number is important.  Which is why I care so much
about it :-)

I think/hope we can agree that “Bitcode compatibility” is an obsolete notion to
encode into the version number - from a historical perspective, we only used
that as rationale because it happened to align well for the 1.9 to 2.0
conversion and then used it as an excuse to shed some legacy in the 3.0
timeframe.

Given that, and given that we have a time based release, we should either leave
the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning model
3.9/4.0/5.0/6.0 or 3.9/40/41/42).

-Chris

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