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

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Sun Jun 26 10:01:27 PDT 2016


I also believe this is the simplest versioning scheme*. It eliminates all
future debates on this topic (e.g, when to bump major version etc) and
solves the problem once and for all --  which is another plus :)

*) similar suggestions a) start from 4, increase by 1; b) start from 40,
increase by 1.   Date based scheme is also a variant of it.

David


On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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
>>
>
> _______________________________________________
> 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/20160626/396b0ba6/attachment.html>


More information about the llvm-dev mailing list