|
| 1 | +# The PSFramework Reliability Promise |
| 2 | +## About |
| 3 | + |
| 4 | +The PSFramework is designed as a platform for others to build their code upon. |
| 5 | +As such, there is a special need for reliability and stability of code. |
| 6 | +This is my promise on how I ensure it is safe to use and safe to rely upon. |
| 7 | + |
| 8 | +## Supported Platforms |
| 9 | + |
| 10 | +This module is supported on: |
| 11 | + |
| 12 | + - Windows PowerShell 3+ (And Windows 6.1 and later) |
| 13 | + - PowerShell Core 6.0+ (Any OS; Stable Release only) |
| 14 | + - PowerShell Core 6.0+ (Any OS; Preview support; Limited support only*) |
| 15 | + |
| 16 | +*Generally, Platform compatibility issues take top priority, having me drop any other issues to fix them. |
| 17 | +For preview editions of PowerShell Core this priority may not apply. |
| 18 | + |
| 19 | +## No breaking change (?) |
| 20 | + |
| 21 | +The greatest risk to relying on foreign code is that that code might introduce a breaking change, thereby breaking your code without you doing anything but deploying a latest version of it. |
| 22 | + |
| 23 | +Therefore, my one greatest promise is this: |
| 24 | + |
| 25 | +> No Breaking Changes* |
| 26 | +
|
| 27 | +That is, if a feature has reached deployment stage, I will not introduce breaking changes whatsoever, except for under some very limited and constrained circumstances. |
| 28 | +And even then I'll try not to if I somehow can. |
| 29 | + |
| 30 | +## Coverage |
| 31 | + |
| 32 | +Now what is covered by this promise: |
| 33 | + |
| 34 | + - All functions and cmdlets signatures. Any current parameterization will keep being valid and produce the same result. |
| 35 | + - All logging providers. Configuration and default behavior cannot be changed. |
| 36 | + - All parameter classes will keep understanding current input (they may _also_ learn new things however) |
| 37 | + - All validation attributes will keep accepting the current definition (new definitions may be introduced however) |
| 38 | + - Any otherwise advertised feature on the [documentation site](https://psframework.org/documentation/documents/psframework.html) |
| 39 | + |
| 40 | +Not covered by this promise: |
| 41 | + |
| 42 | + - Preview features. All new commands that are being released are considered to be in preview for one month. This is designed to allow for initial user feedback to be implemented. Note: This only applies to the initial command release, _not_ to any later updates that were made after the preview stage was over. |
| 43 | + - Any other internal library mechanics. Some of them need to be public for script funtions to access them. That does _not_ imply they are for public consumption (You may use them for that, but at your own risk). |
| 44 | + - UI User Interaction. Messages written to the host intended for a human consumption may be changed in how they are being displayed. The previous state however must be available using configuration (thus changes to the _default_ behavior can be made, as long as the old state can be reintroduced). |
| 45 | + - Experimental features. Any feature listed as experimental below is considered to be exempt from this policy. |
| 46 | + - System mandated change: If a feature needs to be adapted in order for it to be operable on all supported platforms (for example an active conflict with PowerShell Core), then that is an overriding technical need to change it. |
| 47 | + - A feature undergong the Process of Change. |
| 48 | + |
| 49 | +## Process of Change |
| 50 | + |
| 51 | +One of the great limitations of a "No Breaking Change" policy is that in some few cases, keeping to support the old ways incurs a penalty, a cost. |
| 52 | +Whether that is hurt performance or undesired environment impact. |
| 53 | +In order to not fully prevent improvement in those scenarios, there shall be implemented a public change process: |
| 54 | + |
| 55 | +For each desired breaking change, an RFC most be posted as an issue, describing the reason for this change and the benefits it brings. |
| 56 | +This RFC will be open for discussion for three months. |
| 57 | +If these three months pass and no convincing argument against it have been brought forward, the suggested change will be marked as a pending change: |
| 58 | + |
| 59 | + - The way of operation that will be broken by that change will be declared deprecated. |
| 60 | + - The affected feature will be updated to include a warning if a deprecated way of using it is detected, to warn about the impeding change. |
| 61 | + - On Windows Systems, use of a deprecated functionality will generate a warning eventlog event in the PowerShell Eventlog (ID: 666; Category: 1; EntryType: Warning; Source: PowerShell) |
| 62 | + - Nine months after the RFC is approved, the breaking change may be implemented. |
| 63 | + |
| 64 | +## Pending Change |
| 65 | + |
| 66 | +There are currently no breaking changes pending |
| 67 | + |
| 68 | +## Experimental features |
| 69 | + |
| 70 | +There currently are no experimental features in the PSFramework |
0 commit comments