> -----Original Message----- > From: hwennb...@google.com [mailto:hwennb...@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-...@lists.llvm.org; Release- > testers; cfe-dev; openmp-dev (openmp-...@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-...@lists.llvm.org> wrote: > > > > > >> -----Original Message----- > >> From: llvm-dev [mailto:llvm-dev-boun...@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-...@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 <t...@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
