Maintained apps: apps that are stable and/or complete and will be maintained against a specific version of the MELD framework.
Maintained brances: versions of MELD clients core used by maintained apps which are branched and updated only for library dependencies only (no new features).
A list of maintained apps and their maintained branches is kept on github.
When library dependencies are updated in master, the person who applies the change must also apply it to all maintained branches. App developers therefore have the choice of following the main branch (along with any breakage and subsequent fixing), or declaring a maintained branch.
If an app moves back to follow the main branch, the developer should deprecate the need for a maintained branch and update the list of maintained apps.
If an update to a maintained branch breaks a maintained app, an app developer may decide to revert to the last known working version of the maintained branch. Doing so effectively moves the app into an archive mode which won’t receive updates for library dependencies (via a maintained branch). In this situation the need for a maintained branch should be removed from the list of maintained apps.
Principles for maintaining the MELD codebase
- Realise new functionality additively wherever possible.
- Rather than changing or replacing existing behaviour.
- Remember this is research software and we need to care for maintained apps.
- Defunct projects cannot always maintain apps but will still want to demo them.
- Minimise the number of maintained branches wherever possible.
- Apps should share maintained branches whenever possible.
Policies for updating & maintaining main branch
Implementation committee (‘IC’) members:
- David Lewis (University of Oxford)
- David Weigl (University of Music and Performing Arts Vienna)
Steering committee (‘SC’) members:
- David Lewis (University of Oxford)
- Kevin Page (University of Oxford)
- David Weigl (University of Music and Performing Arts Vienna)
Additive non-breaking changes require approval of the IC (only). Changes should be made as a Pull Request asking for Review by all IC members.
Behaviour-breaking changes should be referred to SC, who will decide whether to declare a major version change. All version changes should include a change file.
Contributions are welcome from all parties and projects, including those not represented on the IC or SC. All non-IC contributions will be reviewed by the IC. Requests to join the IC or SC should be raised as a github issue.
From a project management perspective, the decision to accept breaking changes may be influenced by strategic, as well as technical, motivations. e.g. projects should avoid pushing major breaking changes to master close to the end of their funding, unless they are able to continue resolving consequential problems beyond the end of the project.
The IC are responsible for implementing and enforcing this policy.
