Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Michael Kuperstein via lldb-dev]

It would probably better for whoever wrote this text to pipe in, but I
think the idea is that (X+1).0 is supposed to be a kind of a "bridge"
release.

That is, if you have legacy IR files that contain dropped features, or if
the IR format changed significantly, you can still use the (X+1).0
auto-upgrade (which may be fairly complex) to read them, but this
auto-upgrade complexity may be dropped in (X+1).1.
I'm not completely sure this makes sense, but this is how I've always
understood it.

On Mon, Jun 13, 2016 at 10:22 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 13 June 2016 at 18:02, Rafael Espíndola 
> wrote:
> > It is documented at
> >
> > http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>
> This is weird...
>
> "The bitcode format produced by a X.Y release will be readable by all
> following X.Z releases and the (X+1).0 release."
>
> Why (x+1).0 ?
>
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 13 June 2016 at 18:30, Michael Kuperstein  wrote:
> It would probably better for whoever wrote this text to pipe in, but I think
> the idea is that (X+1).0 is supposed to be a kind of a "bridge" release.

That rings a bell... but I have to be honest, it's weird...

Now, well, as Rafael said originally, our policy doesn't state how
long we can go (3.10, 3.11 or 3.9 -> 4.0), nor it does *require* that
we change the ABI on (X+1). FWIW, the Linux kernel seems to be going
that way, too.

Whatever works, but it would be good to choose something based on
consensus and document.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

On 13 June 2016 at 13:30, Michael Kuperstein  wrote:
> It would probably better for whoever wrote this text to pipe in, but I think
> the idea is that (X+1).0 is supposed to be a kind of a "bridge" release.
>
> That is, if you have legacy IR files that contain dropped features, or if
> the IR format changed significantly, you can still use the (X+1).0
> auto-upgrade (which may be fairly complex) to read them, but this
> auto-upgrade complexity may be dropped in (X+1).1.
> I'm not completely sure this makes sense, but this is how I've always
> understood it.

I think that is the idea. When the text was written it was just
codifying existing practices (3.0 could read 2.X).

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Renato Golin via lldb-dev]

On 13 June 2016 at 18:02, Rafael Espíndola  wrote:
> It is documented at
>
> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

This is weird...

"The bitcode format produced by a X.Y release will be readable by all
following X.Z releases and the (X+1).0 release."

Why (x+1).0 ?

--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

> 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

http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Tom Stellard via lldb-dev]

On Fri, Jun 10, 2016 at 01:38:22PM -0700, Hans Wennborg via llvm-dev wrote:
> Hello everyone,
> 
> It's time to start planning for the 3.9 release.
> 
> Please let me know if you'd like to help providing binaries and
> testing for your favourite platform.
> 
> I propose the following schedule:
> 
> - 18 July: Create the release branch; build and test RC1 soon thereafter.
> 
> - 1 August: Tag, build and test RC2. Any unfinished features need to
> be turned off by now. As we get closer to the release, the bar for
> merging patches rises.
> 
> - 22 August: Tag 3.9.0-final. The release ships when binaries are ready.
> 
> 
> Also, I have three more questions for the community:
> 
> 1) Right after the branch, the version number of the trunk will be
> incremented. I assume this means bumping the major version number,
> taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.
> 

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.

-Tom




> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
> 
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?
> 

This is a great idea.

-Tom

> Let me know what you think.
> 
> Cheers,
> Hans
> 
> 
>  [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Robinson, Paul via lldb-dev]

> -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  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-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

On 13 June 2016 at 10:11, Tom Stellard  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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Rafael Espíndola via lldb-dev]

> 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.

Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev