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 <h...@chromium.org> wrote: > On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev > <cfe-...@lists.llvm.org> 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. > > 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-...@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 > > > > > > _______________________________________________ > > 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
