On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner <clatt...@apple.com> wrote: > On Jun 27, 2016, at 4:57 PM, Hans Wennborg <h...@chromium.org> wrote: >>> Eh, if we're switching to a completely unrelated versioning scheme, it >>> doesn't seem completely unreasonable. >>> >>> We could also count how many time-based releases we have had and use that... >>> >>> :: shrug :: >>> >>> I think counting from 4 or counting from 40 are all fine ways to number >>> releases. >> >> >> This is what I arrived at after my weekend of thinking about version numbers: >> >> While there's been many good arguments for doing something different >> and revising our versioning scheme, I really just want to bump the >> number with the least amount of work possible. >> >> When we branch for 3.9, my plan is to bump trunk to 3.10, and then >> focus my attention on getting 3.9 into a good state and shipping it. >> >> After the branch, if someone wants to promote trunk to 4.0 because of >> a feature, or because the 3-series is "done", go ahead. If someone >> wants to spearhead getting us onto a scheme where we increment major >> for each release, that's fine too, but I'm not going to drive it. >> >> Thanks everyone for participating in the discussion. Hopefully this >> result is not too disappointing. > > I continue to think that 3.10 is the least defensible option out there. We > have a time based release process with no mechanism or attempt to align > behind “big” releases that could bring is to a 4.x number. You might as well > call the release “10” at this point, since the "3.” will become archaic > legacy that we can’t shed. > > Trust me, I’ve seen this happen several times in the past in multiple > different products (both open source and proprietary), and have had success > leading one to a more predictable release number pattern like I’m advocating > for. This is a problem that we are simply walking into by naming it 3.10, > there is no reason to do that. > > I still don’t understand what “confusion” could be caused by going from 3.9 > to 4.0. Could someone please elaborate on what the problem is that needs > solving? If it is that people don’t understand what is major about the > release, I would say “who cares”?
I think the main issue (besides users asking what's the big change in 4.0, which I agree is not a big problem) is that the bitcode compatibility policy is tied to the major version number. But if you really insist on 4.0 rather than 3.10, I will of course honour that. Cheers, Hans _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
