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-up
I've split the version discussion off into a new thread ("What version
comes after 3.9?") and CC'd everyone discussing it here so far.
On Mon, Jun 13, 2016 at 11:23 AM, Mehdi Amini via llvm-dev
wrote:
>
>> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev
>> wrote:
>>
>>> The 4.1 relea
> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev
> 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
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 orig
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 forma
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 ?
> 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-timi
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 s
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:
>
>
> -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:
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 re
> 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 ob
12 matches
Mail list logo
