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

[Hans Wennborg via cfe-dev]

On Mon, Jun 13, 2016 at 9:24 AM, Robinson, Paul via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
>
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>> Rafael Espíndola via llvm-dev
>> Sent: Monday, June 13, 2016 7:47 AM
>> To: Tom Stellard
>> Cc: llvm-dev; Release-testers; openmp-dev (openmp-dev at lists.llvm.org);
>> LLDB Dev; cfe-dev
>> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
>>
>> On 13 June 2016 at 10:11, Tom Stellard <tom at stellard.net> wrote:
>> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
>> >> > The 4.1 release gives us the opportunity to drop support for 3.x
>> >> > bitcode formats, so  I don't think we should move to 4.x until we
>> have
>> >> > older bitcode features that we really want to drop.  There should
>> >> > probably be a separate discussion thread about this.
>> >>
>> >> It give the opportunity, not the obligation. Given that I think it is
>> >> an independent issue and would suggest we just keep the revisions
>> >> simple and switch trunk to 4.0.
>> >>
>> >
>> > Hi Rafael,
>> >
>> > The main issue I see with automatically moving to 4.0, is that if a year
>> > from now we decide we want to drop a bitcode feature, we can't really do
>> > it unless we bump the major version again to 5.0.  If we continue on
>> > with 3.x, then we still have the flexibility to drop bitcode features
>> > when we decide it's necessary.
>>
>> OK, I guess that is where your reading of the version differ.
>>
>> I read that we promise that 4.0 will read all of 3.X, but make no
>> further promises. That means that in 4.1 we *can* drop support for all
>> 3.x, keep support for everything or something in the middle. But that
>> is also true for 4.2. So for example it would be valid that
>>
>> * 4.0 reads all of 3.x
>> * 4.1 reads >= 3.1
>> * 4.2 reads >= 3.3
>
> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.
>
> Maybe documenting the release-numbering-semantics policy alongside
> the release-timing policy would be a good idea?

If someone could just let me know what the policy actually is.. ;-)