#529 A method for marking a feature as "beta" in the Guidelines
We already have a method for deprecating features we will be removing from the Guidelines (or at least, several strategies for doing so), which are designed to warn people long in advance that something may disappear or change. We need something similar for new features which are viewed as experimental, but which we want to introduce into a release of the Guidelines so that users can see them, try them and provide feedback, with the understanding that they are not yet stable.
There are two possible approaches to this: one is to fork the Guidelines and have a "beta build" in which new features are available which don't appear in the stable release. This may entail a lot of work in that changes to the main trunk will have to be carefully merged into the beta build regularly, so that the only differences between them are the experimental features; it also means that users would have to purposely go and find the beta build and use it before we could get feedback.
A simpler approach is a simple method for marking a component of the specification as "beta". Right now, on e.g. <elementSpec>, we have att.deprecated's @validUntil. We could:
- Change the name of att.deprecated to e.g. att.developmentStatus
- Add a new attribute (@releaseStatus?) with values of "alpha", "beta", "rc" and "stable" (the default).
- Update Guidelines processing to provide some helpful warning text for any element or attribute that carries a status which is not "stable".
Having this kind of feature would really help as Pure ODD is developed and integrated into the Guidelines over the next couple of years.
Need some use cases for how this would be applied. And is "experimental" the same as being on the path to incorporation into the guidelines?
LB: What features does this provide other than those provided by defining a new ODD?
F2F Raleigh 2014-11-17 rejected the idea of implementing this as described and it would be better to build checking mechanisms to stop this happening at all. There should always be documented in the guidelines. Any experiments should be conducted outside of the guidelines, or backed out before release, or release delayed.