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

[Robinson, Paul via Release-testers]

> -----Original Message-----
> From: hwennborg at google.com [mailto:hwennborg at google.com] On Behalf Of Hans
> Wennborg
> Sent: Monday, June 13, 2016 9:27 AM
> To: Robinson, Paul
> Cc: Rafael Espíndola; Tom Stellard; llvm-dev at lists.llvm.org; Release-
> testers; cfe-dev; openmp-dev (openmp-dev at lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for
> testers
> 
> 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.. ;-)

I think this is probably a case where the best approach is to write up
*some* kind of policy, and then it gets thrashed out in review.
--paulr