Figure out the deal with .PREVIEW versions

[zoffixznet]

Imagine you're a module author who'd makes use of a "preview" feature for the next major language release by using, say, use v6.d.PREVIEW version pragma. Their goal is to make this module work on as many compilers as possible, both those released before a major version release and after.

To ensure the module still works on pre-6.d compilers, it seems the author must use use v6.d.PREVIEW for quite awhile after 6.d-capable compiler release. On Rakudo v6.d currently v.6.PREVIEW is equivalent to just use v6.d

The questions are:

• will .PREVIEW be equivalent to released version, if available, forever or will at some point it'll stop working?
• will this system lead to a huge proliferation of .PREVIEW users simply because they wish to handle as many compiler versions as possible, even those before lang release? Could there be a better system to handle lang previews?

[jnthn]

It's a really good question. Some thoughts:

will .PREVIEW be equivalent to released version, if available, forever or will at some point it'll stop working?

I'd assumed a compiler supports a range of versions, and so will accept anything falling within the endpoints. So on that basis I'd expect it to keep working.

will this system lead to a huge proliferation of .PREVIEW users simply because they wish to handle as many compiler versions as possible, even those before lang release?

I don't know, but note that the inclusion of, say, use v6.e.PREVIEW will mean that code can't run on anything that doesn't understand that. Thus, there's also a pressure not to use it in order to support a wider range of compiler versions (going back further in time) too.

Could there be a better system to handle lang previews?

Quite possibly, but I don't immediately have a better idea.

[vrurg]

I would say with #2852 and #2953 this ticket could be closed.