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

Minor releases procedure

A minor release consists of minor enhancements to files, that are entirely backwards compatible.

A minor release is expected to follow these steps:

  1. A Pull Request is created from its release branch and MUST be reviewed and signed off by at least 2 members of the ontology team.

  2. A pre-release is created from the release branch.

  3. All partner platforms are notified via the Releases mailing list. Platforms will be given 3 working days (excluding weekends & public holidays in all participating countries) to test and respond. Any changes/fixes required will be applied to the release branch and the pre-release updated.

  4. After the pre-release testing period, the Pull Request will then be merged into the master branch and the release branch deleted.

  5. The minor release will then be notified (a minimum of 5 calendar days in advance of release) by broadcast on Slack (through the #releases channel) and GitHub.

  6. After the appropriate notice period, the release will be marked as "Latest Release"

  7. A final mail will be sent to the Release Mailing List confirming completion of the release.

PreviousPatch releases procedureNextMajor releases procedure

Last updated 3 months ago

Was this helpful?

🚧