Update or Retire
This section unpacks the ‘launch and adoption’ stage to open standard development, with a focus on how to make changes to keep the standard robust and relevant or retire it gracefully
Update the standard
Processes in the updates stage are similar to those in the ‘Development’ stage with some key differences. During development, the standard is new, so decisions focus on the features necessary for a robust and stable product.
At the ‘Review’ stage, the standard is in use, so changes will impact a wide variety of adopters – people and organisations using or supporting the standard, data produced using the standard, and models produced using guidance.
The impact of proposed changes should be carefully considered.
Adopters – including data publishers, data users, guidance users, and developers – may be affected in different ways. There may also be an impact on associated legislation, policy, products and services.
Changes to the standard may not affect all or even most adopters, but in some cases might require them to invest to incorporate the changes.
Typically, a major change is a departure from the current standard that introduces breaking changes, which means:
existing tools based on the current version of a standard for data exchange or standard to share vocabulary may not work with the new version
the structure of data produced using the new version of a standard for data exchange may be different from that using the current version
new versions of standard to share vocabulary such as lists and ontologies may include significant, new or updated entries, classifications or hierarchies
models produced using standards for guidance may vary between versions of the open standard
While updating an open standard means investing in changes to the data infrastructure, when done right, these changes can make the standard easier to adopt and use.
It’s important to clearly communicate what the changes are and what impact they will have as early as possible. It should be clear to potential and existing adopters that changes have been made.
Versioning can make it easy to find and distinguish between changes to an open standard.
Versioning uses unique labels to track changes. The labels are usually an increasing number. Minor changes tend to be distinguished from major changes by a suffix for the minor and prefix for the major change.
For example, the first major release may be 1.0, a minor update 1.1, and a second major release 2.0.
Where multiple versions of the standard will be supported, each version may need:
guides and resources that explain how to use the standard, including tutorials for learning, explanations to improve understanding, how-to guides for step-by-step problem-solving and references, which could be the standard in human-readable form
translations of the open standard, guides and documentation and website content (if supporting multiple languages is necessary)
test suites of data or models that both conform and break the standard to demonstrate scenarios adopters may encounter, handle or report
tools for converting, validating and viewing data that uses the standard
code libraries for processing or analysing the standard
Typical activities when updating an open standard include:
deciding on major or breaking changes – releases that could stop existing tools and services from working
considering how many changes to include in the next version as it may be more acceptable to split a large volume of minor changes into separate updates
gaining support from a variety of people and organisations in your community for the new version
announcing changes in good time, allowing adopters to assess and plan for changes internally where needed
Once the scope and management of updates has been decided and agreed, work can begin on development of the new version.
Choose active retirement
‘Retirement’ – when a standard is no longer actively maintained – can happen for a number of reasons.
An open standard may be retired when:
there is no longer funding to maintain the standard
new standards or technology replace the standard
changes in the landscape, including regulation, law, or practice, make the standard unnecessary
Following the Open Stand principles of working in the open, it’s important to keep the standard’s community informed if the standard is to be retired and no longer maintained. This is preferable to passive retirement, where the standard is no longer maintained and disappears without warning.
Typical ways to actively retire a standard include:
circulating the decision within the community using available channels, for example social media, mailing lists, websites, forums or repositories like GitHub
gifting intellectual property to the community or another organisation to continue the upkeep of the standard if necessary
closing down websites and forums to prevent new updates but preserving the web presence – a notice may be added to inform visitors that the standard is no longer maintained
archiving content using websites like Internet Archive, repositories like GitHub or other sites to maintain website information that will be lost once the domain is shut down
Expected outputs
Typical outputs at the end of the update stage include:
a list of changes shared with the community and used to guide the development process
a stable version of the open standard in the form of a new minor or major version of the standard
updated guides and documentation that explain what’s changed and how to use the standard
Last updated