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

Mon Jun 27 10:06:16 PDT 2016

Stable release can use a different numbering space -- a,b,c,d.     4.1a
means the first patch release of 4.1 release, etc.

David

On Mon, Jun 27, 2016 at 8:26 AM, Hans Wennborg <hans at chromium.org> wrote:

> On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
> <cfe-dev at lists.llvm.org> 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.
>
> We can't remove the '.' completely though, as we need it for Tom's
> stable releases.
>
> That's what concerns me about going to the scheme Richard and Rafael
> suggested, of bumping the major version each time: we'd release 4.0,
> and would Tom's dot-release then be 4.1? That would be confusing to
> those who are used to our current scheme. Chris suggested going
> straight to 40 to avoid this, but that also seems a bit extreme.
>
> Thanks,
> Hans
>
>
> >> 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
> >
> >
> > _______________________________________________
> > 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/20160627/67c2b4f6/attachment.html>