llvm dev - Jun 2016 - 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?

- We've never had an x.10 version before; maybe that would be
confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
3.0 and 3.19 -> 4.0).

- Since we do time-based rather than feature-based releases, the major
version number shouldn't mean anything special anyway (e.g. big IR
changes or not), so 4.0?

- Everyone knows that after 9 comes 10, so 3.10 it is. The version is
a tuple after all.

- Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases in
between would correspond to minor version bumps, which would make
sense (and catch up with GCC!).

- It's just a number, no big deal; flip a coin or something.

What do you think?

 - Hans


 [1]. http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

> On Jun 13, 2016, at 4:54 PM, Hans Wennborg <hans at chromium.org>
wrote:
> 
> Breaking this out into a separate thread since it's kind of a separate
> issue, and to make sure people see it.
Thanks!
> 
> 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.
(basically repeating my point of the other thread here)
Bumping the major version number without changing the bitcode compatibility rule
would mean dropping the current guarantee on this aspect. I doubt we want to go
this route without a good reason.

-- 
Mehdi

> 
> - But maybe we want to save 4.0 for when we do have a significant IR
change?
> 
> - We've never had an x.10 version before; maybe that would be
> confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
> 3.0 and 3.19 -> 4.0).
> 
> - Since we do time-based rather than feature-based releases, the major
> version number shouldn't mean anything special anyway (e.g. big IR
> changes or not), so 4.0?
> 
> - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> a tuple after all.
> 
> - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases in
> between would correspond to minor version bumps, which would make
> sense (and catch up with GCC!).
> 
> - It's just a number, no big deal; flip a coin or something.
> 
> What do you think?
> 
> - Hans
> 
> 
> [1]. http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

----- Original Message -----
> From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <cfe-dev at lists.llvm.org>, "LLDB Dev"
<lldb-dev at lists.llvm.org>,
> "openmp-dev (openmp-dev at lists.llvm.org)" <openmp-dev at
lists.llvm.org>
> Cc: "r jordans" <r.jordans at tue.nl>, "Paul
Robinson" <Paul_Robinson at 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.

 -Hal
> 
> - We've never had an x.10 version before; maybe that would be
> confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
> 3.0 and 3.19 -> 4.0).
> 
> - Since we do time-based rather than feature-based releases, the
> major
> version number shouldn't mean anything special anyway (e.g. big IR
> changes or not), so 4.0?
> 
> - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> a tuple after all.
> 
> - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases
> in
> between would correspond to minor version bumps, which would make
> sense (and catch up with GCC!).
> 
> - It's just a number, no big deal; flip a coin or something.
> 
> What do you think?
> 
>  - Hans
> 
> 
>  [1].
>  http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> ----- Original Message -----
> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
> > "openmp-dev (openmp-dev at lists.llvm.org)" <openmp-dev
at lists.llvm.org>
> > Cc: "r jordans" <r.jordans at tue.nl>, "Paul
Robinson" <
> Paul_Robinson at 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.
>
At least naively, I'd expect opaque pointer types to be backwards
compatible (ie: we can load old bitcode and just strip all the pointer
types and bitcasts). But perhaps it still meets the bar of a big change &
may be worth shedding all the backwards compatibility weight sooner rather
than later after the change, for sure.

(as to the main issue - yeah, I tend to agree with you/Mehdi, etc - go to
3.10 and so on, until we decide it's worth breaking back-compat - do we
need to update any wording about our back-compat guarantee that says we
won't do the inverse (4.3 -> 5.0 because we decide we have another
breaking
change), though? Since we'll demonstrated that primary version bumps
aren't
on a strict ~5 year cycle anymore - probably don't need to do anything, but
just a thought)

- Dave

>
>  -Hal
>
> >
> > - We've never had an x.10 version before; maybe that would be
> > confusing? Perhaps it's simply time to move on (like Linux 2.6.39
->
> > 3.0 and 3.19 -> 4.0).
> >
> > - Since we do time-based rather than feature-based releases, the
> > major
> > version number shouldn't mean anything special anyway (e.g. big IR
> > changes or not), so 4.0?
> >
> > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> > a tuple after all.
> >
> > - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases
> > in
> > between would correspond to minor version bumps, which would make
> > sense (and catch up with GCC!).
> >
> > - It's just a number, no big deal; flip a coin or something.
> >
> > What do you think?
> >
> >  - Hans
> >
> >
> >  [1].
> >  http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160613/b13712a1/attachment.html>

On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
>
> > On Jun 13, 2016, at 4:54 PM, Hans Wennborg <hans at
chromium.org> wrote:
> >
> > Breaking this out into a separate thread since it's kind of a
separate
> > issue, and to make sure people see it.
>
> Thanks!
>
> >
> > 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.
>
> (basically repeating my point of the other thread here)
> Bumping the major version number without changing the bitcode
> compatibility rule would mean dropping the current guarantee on this
> aspect. I doubt we want to go this route without a good reason.
>
Completely agree with you here: unless we have a reason to break backwards
compatibility at the bit code level for this release, I don't see a
compelling reason to bump the major version number to 4.0.  As such, I
would expect that the next release would be 3.10.

> --
> Mehdi
>
>
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> change?
> >
> > - We've never had an x.10 version before; maybe that would be
> > confusing? Perhaps it's simply time to move on (like Linux 2.6.39
->
> > 3.0 and 3.19 -> 4.0).
> >
> > - Since we do time-based rather than feature-based releases, the major
> > version number shouldn't mean anything special anyway (e.g. big IR
> > changes or not), so 4.0?
> >
> > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> > a tuple after all.
> >
> > - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases in
> > between would correspond to minor version bumps, which would make
> > sense (and catch up with GCC!).
> >
> > - It's just a number, no big deal; flip a coin or something.
> >
> > What do you think?
> >
> > - Hans
> >
> >
> > [1].
> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160613/d50365f4/attachment.html>

On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> ----- Original Message -----
> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
> > "openmp-dev (openmp-dev at lists.llvm.org)" <openmp-dev
at lists.llvm.org>
> > Cc: "r jordans" <r.jordans at tue.nl>, "Paul
Robinson" <
> Paul_Robinson at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/9ef9b48e/attachment.html>

On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> ----- Original Message -----
> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
> > "openmp-dev (openmp-dev at lists.llvm.org)" <openmp-dev
at lists.llvm.org>
> > Cc: "r jordans" <r.jordans at tue.nl>, "Paul
Robinson" <
> Paul_Robinson at 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.
>
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.

 -Hal
>
> >
> > - We've never had an x.10 version before; maybe that would be
> > confusing? Perhaps it's simply time to move on (like Linux 2.6.39
->
> > 3.0 and 3.19 -> 4.0).
> >
> > - Since we do time-based rather than feature-based releases, the
> > major
> > version number shouldn't mean anything special anyway (e.g. big IR
> > changes or not), so 4.0?
> >
> > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> > a tuple after all.
> >
> > - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases
> > in
> > between would correspond to minor version bumps, which would make
> > sense (and catch up with GCC!).
> >
> > - It's just a number, no big deal; flip a coin or something.
> >
> > What do you think?
> >
> >  - Hans
> >
> >
> >  [1].
> >  http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/86cd2e05/attachment.html>

Thank you for raising this question! I think 3.10 makes sense until we
have a strong enough breaking change (in anything, not just LLVM bit
code) to warrant bumping to 4.0.

~Aaron

On Mon, Jun 13, 2016 at 7:54 PM, Hans Wennborg via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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?
>
> - We've never had an x.10 version before; maybe that would be
> confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
> 3.0 and 3.19 -> 4.0).
>
> - Since we do time-based rather than feature-based releases, the major
> version number shouldn't mean anything special anyway (e.g. big IR
> changes or not), so 4.0?
>
> - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> a tuple after all.
>
> - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases in
> between would correspond to minor version bumps, which would make
> sense (and catch up with GCC!).
>
> - It's just a number, no big deal; flip a coin or something.
>
> What do you think?
>
>  - Hans
>
>
>  [1]. http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org>
wrote:
> 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.
Thanks everyone for chiming in.

Please correct me if I misrepresent your opinion here, but I need to
try and summarize this thread for my own sanity:

The thread started out with lots of support for 3.10, the reasoning
being roughly that we shouldn't bump the major version number unless
we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
Chandler, Anton, Eric, Aaron, Sean, Vikram).

Richard suggested that since we do time-based rather than
feature-based releases, the distinction between a release with or
without major changes is arbitrary, and we should move to a scheme
where we update the major version number on each release (4.0, 5.0,
etc.) with minor releases in between (4.1, 5.1, ..).

Chris advocated for "keep adding 0.1 to each major release" (in the
decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
suggest this. "I do not think it is reasonable at all to go to
'3.10'
after '3.9', because we will never get to '4.0'."

Chris then expressed support for alternatively just incrementing the
major version each time, as Richard suggested, but starting at 40.

Rafael expressed support for the above, but starting at 4.0: "It is
simply not worth the time to try to figure out what is 'major' in a
project with so many different uses."

Chandler said he didn't like Chris's "keep adding 0.1 to each major
release" scheme: "we shouldn't just go from 3.9 to 4.0 because of
some
decimal correspondence", and said he was open to either going to 3.10
with the current major/minor split, or if we don't want that, use
Richard's suggestion.

Michael pointed out that if we do change the numbering scheme,
changing the binary compatibility guarantee to something time-based
isn't equivalent to what we currently have.



So, it seems we're at an impasse with several folks in favour of 3.10,
Chris speaking out strongly against it, and Richard's option which has
some traction and which no one's disagreed with so far, but which
would be a bigger change.

I'll have a think about this over the weekend.

Cheers,
Hans

On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Richard suggested that since we do time-based rather than
> feature-based releases, the distinction between a release with or
> without major changes is arbitrary, and we should move to a scheme
> where we update the major version number on each release (4.0, 5.0,
> etc.) with minor releases in between (4.1, 5.1, ..).
If we are truly committed to doing time-based releases, we can switch
to time-based version numbers, Year.Month, for example, if we were to
release in June it would be 16.06.  We can use an extra digit for
minor releases.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at
gmail.com>*/

> On Jun 24, 2016, at 7:41 PM, Hans Wennborg <hans at chromium.org>
wrote:
> 
> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org>
wrote:
>> 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.
> 
> Thanks everyone for chiming in.
> 
> Please correct me if I misrepresent your opinion here, but I need to
> try and summarize this thread for my own sanity:
> 
> The thread started out with lots of support for 3.10, the reasoning
> being roughly that we shouldn't bump the major version number unless
> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
> Chandler, Anton, Eric, Aaron, Sean, Vikram).
Since I’m mentioned here in support of 3.10, I’d like to correct by repeating
what I wrote previously in this thread:

"To clarify my point: I don't have a particular opinion about bumping
the major number for whatever other reason than breaking the compatibility, but
I'd probably suggest that we rewrite the compatibility policy to say
something like "The current LLVM version support loading any bitcode since
version 3.0”.”

Otherwise either Rafael last proposal (starting at 4.0 and +1 for every
release), or Dmitri (“ubuntu-like” date-based numbering) are perfectly fine for
me.

— 
Mehdi

> 
> Richard suggested that since we do time-based rather than
> feature-based releases, the distinction between a release with or
> without major changes is arbitrary, and we should move to a scheme
> where we update the major version number on each release (4.0, 5.0,
> etc.) with minor releases in between (4.1, 5.1, ..).
> 
> Chris advocated for "keep adding 0.1 to each major release" (in
the
> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
> suggest this. "I do not think it is reasonable at all to go to
'3.10'
> after '3.9', because we will never get to '4.0'."
> 
> Chris then expressed support for alternatively just incrementing the
> major version each time, as Richard suggested, but starting at 40.
> 
> Rafael expressed support for the above, but starting at 4.0: "It is
> simply not worth the time to try to figure out what is 'major' in a
> project with so many different uses."
> 
> Chandler said he didn't like Chris's "keep adding 0.1 to each
major
> release" scheme: "we shouldn't just go from 3.9 to 4.0
because of some
> decimal correspondence", and said he was open to either going to 3.10
> with the current major/minor split, or if we don't want that, use
> Richard's suggestion.
> 
> Michael pointed out that if we do change the numbering scheme,
> changing the binary compatibility guarantee to something time-based
> isn't equivalent to what we currently have.
> 
> 
> 
> So, it seems we're at an impasse with several folks in favour of 3.10,
> Chris speaking out strongly against it, and Richard's option which has
> some traction and which no one's disagreed with so far, but which
> would be a bigger change.
> 
> I'll have a think about this over the weekend.
> 
> Cheers,
> Hans

I also support Chris's position of 4.0, 4.1 etc. I don't think
"majorness"
is that important, and we can sort out the bit code compatibility story
some other way.

Sent from phone
On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org>
wrote:
> > 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.
>
> Thanks everyone for chiming in.
>
> Please correct me if I misrepresent your opinion here, but I need to
> try and summarize this thread for my own sanity:
>
> The thread started out with lots of support for 3.10, the reasoning
> being roughly that we shouldn't bump the major version number unless
> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
> Chandler, Anton, Eric, Aaron, Sean, Vikram).
>
> Richard suggested that since we do time-based rather than
> feature-based releases, the distinction between a release with or
> without major changes is arbitrary, and we should move to a scheme
> where we update the major version number on each release (4.0, 5.0,
> etc.) with minor releases in between (4.1, 5.1, ..).
>
> Chris advocated for "keep adding 0.1 to each major release" (in
the
> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
> suggest this. "I do not think it is reasonable at all to go to
'3.10'
> after '3.9', because we will never get to '4.0'."
>
> Chris then expressed support for alternatively just incrementing the
> major version each time, as Richard suggested, but starting at 40.
>
> Rafael expressed support for the above, but starting at 4.0: "It is
> simply not worth the time to try to figure out what is 'major' in a
> project with so many different uses."
>
> Chandler said he didn't like Chris's "keep adding 0.1 to each
major
> release" scheme: "we shouldn't just go from 3.9 to 4.0
because of some
> decimal correspondence", and said he was open to either going to 3.10
> with the current major/minor split, or if we don't want that, use
> Richard's suggestion.
>
> Michael pointed out that if we do change the numbering scheme,
> changing the binary compatibility guarantee to something time-based
> isn't equivalent to what we currently have.
>
>
>
> So, it seems we're at an impasse with several folks in favour of 3.10,
> Chris speaking out strongly against it, and Richard's option which has
> some traction and which no one's disagreed with so far, but which
> would be a bigger change.
>
> I'll have a think about this over the weekend.
>
> Cheers,
> Hans
> _______________________________________________
> 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/20160626/4e4ccd5f/attachment-0001.html>