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

[Robinson, Paul via cfe-dev]

> -----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?
--paulr

> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev