On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth <chandl...@gmail.com> wrote:
> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev < > cfe-...@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-...@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-...@lists.llvm.org> wrote: >>> >>>> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <h...@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-...@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-...@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> >>> >> _______________________________________________ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
