[title]Maintenance status[/title]

[title="2"]Branch maintenance[/title]

As based on our policy described in our [page="docs:tut_software_feedback"]Problem and feedback reports, and development policies[/page] tutorial, current Composr branches are maintained as follows...

[block]main_version_support[/block]

[title="2"]Feature maintenance[/title]

Composr is an enormous system that contains a number of highly specialist features as well as integration with third-party systems that are subject to unpredictable change.

It isn't feasible for us to guarantee all this will keep working as things evolve internally and externally, often at a rapid pace outside our control.

We track functionality that has a moderate to high risk of breakage. This:
1) Helps us provide a reliable product and ecosystem by informing users of what they need to keep an eye on and budget for
2) Allows us to solicit funding for on-going support of rare or fragile functionality (we think it's fair for the up-keep of highly specialist and advanced functionality to be directly paid for by those who need it)
3) Allows us to mark off unreliable functionality so that we don't need to force developers to maintain every specialist cross-cutting feature that has ever been added to Composr (sometimes things are worth keeping, but only worth actively maintaining if there's funding or a large user-base)
4) Helps direct testing efforts
5) Provides us a broad reminder of what needs on-going reappraisal
Further discussion and justification may be found in and directed to the [url="original tracker issue"]https://compo.sr/tracker/view.php?id=2578[/url].

Bugs may be reported for non-actively-maintained functionality. However, the speed at which they will be fixed (or if they get fixed at all) will depend on developer availability and their sense of priority.

[title="3"]Maintenance status table[/title]

[block]composr_maintenance_status[/block]

[title="3"]Sponsorship[/title]

Sponsorship involves taking direct responsibility including testing and bug fixing, or paying someone (such as ocProducts) to do that. In some cases it may also involve taking some up-stream responsibility, funding or maintaining frameworks or projects that Composr functionality is depending on.

The cost of sponsoring functionality may vary greatly, from hours of time per year to weeks per year. For more information [page=":contact_us"]contact the developers[/page].

Note that sponsoring functionality initially is not the same as sponsoring on-going maintenance. Once something is implemented and delivered there isn't a guarantee it can be maintained forever without on-going sponsorship.

[title="3"]Non-bundled addons[/title]

No non-bundled addon will be put into the table [i]unless[/i] it is being officially supported by the core developers. The default assumption should be that no non-bundled addon is supported by the core developers to the same level of reliability and quality as Composr itself. If you want a non-bundled addon added to the list you can request to sponsor it though. Most non-bundled addons will regardless be supported by bug fixes, and automatically updated as Composr APIs change -- but not to the normal expected quality, and not proactively tested.

[title="3"]Third-party software[/title]

The above list does not include third-party software (such as CKEditor) that is directly integrated into Composr. We do not usually take direct responsibility for improving this software or for regularly re-synching it. Sponsors may therefore want to consider sponsoring upstream projects too, and sponsoring refreshes of those within Composr. A list of third-party software may be found on the [url="Sync with upstream"]https://compo.sr/tracker/view.php?id=651[/url] tracker issue.
