[Release-testers] [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

Renato Golin via Release-testers release-testers at lists.llvm.org
Mon Jun 13 06:57:21 PDT 2016

On 13 June 2016 at 14:23, David Chisnall via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
> I don’t think that this makes it simple for anyone.  Existing packaging tools understand dot notation and know that 3.10 > 3.9, even if interpreting the dot as a decimal point would mean that it didn’t.  Without this kind of special handling, they’d be very confused by 3.4.1, which isn’t even a valid number.

Hi David,

This is indeed at odds with the rest of the open source community, but
it's what we've been doing for a long time... I don't particularly
like it myself, but I don't think it's evil.

> LLVM minor revisions break ABI and API compatibility and bugfix revisions don’t.  There is an expectation that major revisions will break the bitcode format, so releasing a 4.0 version but saying ‘this one doesn’t actually break it’ will be confusing.  Particularly if we then release a 5.0 that does, after a 4.5 that doesn’t.

Well, the idea here is that in "3.9.0", "3.9" is the major "number"
and ".0" is the minor. I'm not saying it's a good scheme (because
tools already understand the other one), but in essence, we *do* break
all stuff between "majors", which means as much from 3.7 to 3.8 as it
does from 3.9 to 4.0.

> That said, in general I’d prefer if we used semantic versioning and stopped releasing major versions with a bump of the minor version number.

I weekly support this, as it is my preferred scheme, and all OSS tools
already understand those *very* well indeed. But I wouldn't want to
enforce it for this July. :)

Maybe we can think of 4.0 as the last of the "weird major release",
and plan well in advance to move to 5.0 when we're ready, not when the
clock ticked. But that could bring a whole lot of other things like
holding off features during code freeze, have multiple branches in Git
for experimental features, etc. which I'd *also* welcome, but all in
good time. Let's move to Git-only first.


More information about the Release-testers mailing list