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

Patch releases procedure

A patch release is a simple bug fix or fixes, that are entirely backwards compatible.

A patch release must be reviewed and signed off by at least 1 member 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. Platforms will be given 1 working day (excluding weekends & public holidays in all participating countries) to test & respond.

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

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

A patch release will then be notified (a minimum of 24 hours in advance of release) by broadcast on Slack (through the #releases channel) & Announcement on 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.

PreviousUpdates to the ontologyNextMinor releases procedure

Last updated 2 months ago

Was this helpful?

🚧