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)

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>

On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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).
Since there seems to be some kind of rough consensus forming around
the idea of moving towards a model with x.y version numbers where we
increment x every six months and y for the "dot" releases in between,
let's take it to a code review:

http://reviews.llvm.org/D21821

What angles am I missing? I'm sure this can break the world in
interesting ways. (It looks like Clang's cmake config is already set
up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL).

 - Hans

> On 2016-Jun-28, at 16:22, Hans Wennborg via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 
> On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> 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).
> 
> Since there seems to be some kind of rough consensus forming around
> the idea of moving towards a model with x.y version numbers where we
> increment x every six months and y for the "dot" releases in
between,
> let's take it to a code review:
> 
> http://reviews.llvm.org/D21821
> 
> What angles am I missing? I'm sure this can break the world in
> interesting ways. (It looks like Clang's cmake config is already set
> up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL).
For one thing, I can't find the patch on the mailing list ;).  I'm
guessing
you missed adding llvm-commits as a subscriber?