Rafael Espíndola via llvm-dev
2016-Jun-13 14:47 UTC
[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 Cheers, Rafael
Robinson, Paul via llvm-dev
2016-Jun-13 16:24 UTC
[llvm-dev] [3.9 Release] Release plan and call for testers
> -----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.3I 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 > lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hans Wennborg via llvm-dev
2016-Jun-13 16:26 UTC
[llvm-dev] [cfe-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.. ;-)
Renato Golin via llvm-dev
2016-Jun-13 16:54 UTC
[llvm-dev] [cfe-dev] [3.9 Release] Release plan and call for testers
On 13 June 2016 at 17:24, Robinson, Paul via cfe-dev <cfe-dev at lists.llvm.org> wrote:> 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.There isn't one. Never was. The *big* changes from 1.x to 2.x and 2.x to 3.x were coincidental at best. There was no effort to hold features until "the next big release comes out", like GCC. However, I do want us to change to follow what almost all other OSS projects do, so writing it as a policy now may discourage that change and give folks some comfort that their idea has merits. I fundamentally agree with David that we have a poor way of naming releases, and that messes up a lot of infrastructure out there. But we do have one policy, which is to warn of any potentially damaging change with *at least* one release in advance. Until now, we always moved from x.9 to (x+1).0. Not because it was a rule or was written somewhere, but because we did. So, doing it again will yield no surprise. If, OTOH, we create a 3.10, it will be our first two-digit release, and that may, actually, break stuff downstream. So, my proposal on IRC was the following: 1. Get over it, call it 4.0 and release 3.9 as scheduled. 2. *Just after* the release, start the discussion for 5.0 This way we'll have at least 5 years to get it right, and people will know (we can document that) that changes are coming. But we can also change from (ex) 4.3 to 5.0 as soon as we agree that we'll do that. My point for the delay is two-fold: 1. Changing the number is not just about naming, it's about behaviour. We'll be telling the world that Clang/LLVM 3.x should work with *any* 3.x components, which is *not* true today. 2. We'll give time for people to agree or disagree, before we name the release on SVN. People release Git-versions of LLVM and call them "llvm-3.9-git". Imagine if we create "llvm-3.10-git" but we decide to change later on to 4.0? So, let's discuss about code freeze, feature branches, stable releases, etc, *first*. But for that, it'd be good to get the SVN vs. Git out of the way even sooner, so, we're talking years, here... cheers, --renato
Rafael Espíndola via llvm-dev
2016-Jun-13 17:02 UTC
[llvm-dev] [3.9 Release] Release plan and call for testers
> 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?It is documented at llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility Cheers, Rafael
Maybe Matching Threads
- [3.9 Release] Release plan and call for testers
- [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
- What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
- [3.9 Release] Release plan and call for testers
- [Openmp-dev] [cfe-dev] [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)