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

[Xinliang David Li via cfe-dev]

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> 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 :)
>>
>
> Except that we'll have to keep dealing with people who are confused why we
> have two version numbers but they don't mean anything. That's why I think
> if we don't want major/minor going forward, we should remove the '.'
> regardless of what number we pick.
>

I am not sure what the confusion is actually. We can apply the following
test to see if the versioning scheme is simple/non-confusing or not: 1) for
release managers: given the current version, what is the next version going
to be? If it is predictable and not requiring lots of effort like this to
debate, then it is a good scheme (IMO); 2) for compiler/tool users: given
the current version, can I easily find out what the previous version is?
what is the version N releases ahead? If it requires googling, then it is
not a good scheme.

David



>
>>
>> *) 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
>>>
>>>
>> _______________________________________________
>> 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/cfe-dev/attachments/20160626/2c289d5a/attachment.html>