You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I didn't plan this for today but the discussion we've got on IRC is probably requiring continuation.
It is all about the question how to we handle PREVIEW modifier. I proposed to deprecate 6.d.PREVIEW soon after the next rakudo release. Deprecation means that any use of the version in code will produce a compile-time warning. No other side effects. In a couple of release cycles deprecated modifier can be dropped and this is where its use would result in an error.
What is my point behind having PREVIEW dropped over time. Some proposed features for one reason or another may not make it into the release. Their implementations are not to be kept in the core forever (unless their acceptance has been postponed for the next release). Deprecation of PREVIEW is a signal for those still using it to reconsider their code and refactor it to conform to supported releases. Wether or not PREVIEW is removed after that is not that important anymore. But as long as no experimental code bound to it is left in the core – what is the point of keeping it?
This is just one point of view. A short talk on IRC has revealed a few more and I hope will see them here.
The text was updated successfully, but these errors were encountered:
Some proposed features for one reason or another may not make it into the release. Their implementations are not to be kept in the core forever (unless their acceptance has been postponed for the next release). Deprecation of PREVIEW is a signal for those still using it to reconsider their code and refactor it to conform to supported releases.
I think there is a misunderstanding. At least in case of v6.d.PREVIEW, it does not mean that features that were dropped for 6.d release are somehow still supported in v6.d.PREVIEW. In other words, v6.d.PREVIEW is v6.d. And yes, before v6.d was released, v6.d.PREVIEW was allowed to change in any way so it was not recommended (so users who put that into their code did that at their own risk). use v6.d.PREVIEW is simply a way of saying “I want v6.d semantics even though v6.d is not released yet”.
Am I making sense? And if so, is there any other problem with keeping v6.d.PREVIEW available?
I didn't plan this for today but the discussion we've got on IRC is probably requiring continuation.
It is all about the question how to we handle
PREVIEW
modifier. I proposed to deprecate6.d.PREVIEW
soon after the nextrakudo
release. Deprecation means that any use of the version in code will produce a compile-time warning. No other side effects. In a couple of release cycles deprecated modifier can be dropped and this is where its use would result in an error.I also drafted my vision in Building Rakudo paper.
What is my point behind having
PREVIEW
dropped over time. Some proposed features for one reason or another may not make it into the release. Their implementations are not to be kept in the core forever (unless their acceptance has been postponed for the next release). Deprecation ofPREVIEW
is a signal for those still using it to reconsider their code and refactor it to conform to supported releases. Wether or notPREVIEW
is removed after that is not that important anymore. But as long as no experimental code bound to it is left in the core – what is the point of keeping it?This is just one point of view. A short talk on IRC has revealed a few more and I hope will see them here.
The text was updated successfully, but these errors were encountered: