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

Roel Jordans via Openmp-dev openmp-dev at lists.llvm.org
Mon Jun 13 07:04:34 PDT 2016



On 13/06/16 15:57, Renato Golin via Openmp-dev wrote:
> 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.
>

We might use the introduction of the new pass manager structure as the 
excuse for a mayor release (that should have some reasonable impact on 
the organization of the optimizations) or perhaps claim moving to Git as 
a mayor step (though I guess that that's more of an organizational element)?

Cheers,
  Roel

> cheers,
> --renato
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>


More information about the Openmp-dev mailing list