DFC standard specifications
DFC standard specifications
DFC standard specifications
  • Introduction
  • Sources and licences
  • Contact and partners
  • Semantic specifications
    • Business ontology
    • Product ontology
    • Technical ontology
  • Technical specifications
    • Protocols specifications
    • Decentralized identifier matching reference system
    • Specifics API
    • Authentication strategy
    • Architecture representations
    • Order states
  • Prototype specifications
  • 🚧Solid client protocol
  • 🚧Connector
    • Model specifications
    • Semantizer specifications
    • Connector specifications
  • Appendixes
    • Appendix 1. General decisions
      • Federation vs Syndication
      • Stateless or stateful?
      • Service granularity
      • Directionality
      • Identification and authentication
      • Centralized or decentralized data storage
      • Metadata repository
    • Appendix 2. Technical decisions
      • Libraries to develop in semantic
      • Transition strategy fron current to ideal
      • Service standard
      • Serialization
      • Transport layer
      • Multi- or single-resource requests?
      • Right delegation between platforms and DFC
      • Data validity and inferences
    • Appendix 3. Practical Examples
      • Version 1.9
      • Version 1.8.2
      • version 1.7.4
      • version 1.7.3
      • version 1.7.1
      • version 1.7
      • version 1.6.2
      • version 1.6.1
      • version 1.6
      • version 1.5.1
      • version 1.5
      • version 1.3
      • version 1.2
  • Contributing
    • 🚧Procedures
      • Updates to the ontology
        • Patch releases procedure
        • Minor releases procedure
        • Major releases procedure
      • Ontology releases process
      • Taxonomy enrichment
        • Taxonomy updates
    • Platform Notifcations
  • Platform Register
    • Platform Register
Powered by GitBook
On this page

Was this helpful?

  1. Contributing
  2. Procedures
  3. Updates to the ontology

Major releases procedure

A major release consists of significant changes, that are not backwards compatible (i.e. breaking changes).

A major release must be reviewed and signed off by at least 2 members of the ontology team.

At this point a pre-release will be created from the release branch.

All partner platforms will be notified via the Releases mailing list. Partner platforms must respond confirming acceptance of the release before proceeding to public notification.

Any changes/fixes required will be applied to the release branch & the pre-release updated.

After the pre-release is accepted, the release branch will then be merged into the master branch & the release branch deleted.

A major release will then be notified (a minimum of 10 calendar days in advance of release) by broadcast on Slack (through the #releases channel) & GitHub.

After the appropriate notice period, the release will be marked as "Latest Release" A final mail will be sent to the Release Mailing List confirming completion of the release.

PreviousMinor releases procedureNextOntology releases process

Last updated 2 months ago

Was this helpful?

🚧