Ticket #1450 (closed RFC: worksforme)
Improve handling of experimental features
Reported by: | whiteknight | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | none | Version: | |
Severity: | medium | Keywords: | |
Cc: | Language: | ||
Patch status: | Platform: |
Description
I would like to suggest some changes with regards to features labeled "experimental":
- Create an EXPERIMENTAL.pod file to keep experimental items (on their way in) separated from deprecated items (on their way out)
- That features labeled experimental have a certain time-limit. Beyond that time, say two stable releases, we have to make a decision whether the feature is suitable for permanent addition to the API, whether it needs to be improved, or whether it can be safely deleted.
- That we update the #parrotsketch meeting process to regularly evaluate these items for viability
- That we add a ticket Type "experimental" on Trac, and associate all experimental features with a ticket. Many experimental features have associated tickets now as problems that the experimental feature tries to fix. However, these aren't tickets that assure we properly triage these features in a timely manner. Also, not all experimental features are added as a response to a bug.
Input on this issue would be very helpful.
Change History
Note: See
TracTickets for help on using
tickets.