THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Spec Release Process
SPECIFICATION RELEASE PROCESS AND CHECKLISTS
Status: DRAFT (not reviewed yet)
Contents
Introduction
The overall process for releasing a version of the specification can involve many people from different teams within the SPDX workgroups.This document and the accompanying checklists are meant to explain how a change to the specification is drafted, released and the steps and collateral that need to be updated along the way. This should serve to not only clarify the process for the SPDX Community but to also avoid any bumps in the road along the way.
The Process
Updates to the specification are normally planned and appear on the SPDX Roadmap. From time to time and as circumstances dictate, smaller point revisions to the specification (i.e. a dot version) will be announced.
Sources for changes to the specification normally come from bug reports in the bugzilla system maintained by the Linux Foundation for SPDX. Items being incorporated into the specification will have their target release set to the version of the SPDX specification being drafted (i.e. 1.2, 1.3, 2.0, etc). Other possible sources for incorporation can come from planned tooling plugfests, feedback from users and so forth. In general, these will be documented as bugs before inclusion.
When work is planned on a new version, the Technical team lead will announce the version on the general mailing list along with a short summary of what changes are going to be addressed (we may not yet know "how" they will be fixed). The Business team will then update the Roadmap (if necessary) along with the predicted release date. Anyone wishing to participate in the drafting/review of the specification should be on the Tech team mailing list and if possible attend the tech team calls.
Work on the specification will done using Google Docs. Non editors for the release can review and comment there. Editors will have access to make changes. Editors get edit privilege from the Tech team lead. You are strongly encouraged to be part of the process, commenting long the way. Nothing is worse then getting to the end and then realizing one or more individuals have issues with something. Note: Google docs offers some advantages over using the wiki for editing like this. In the future we may use something else.
As work progresses on the draft, periodic review versions will be announced by the Tech Team lead on the SPDX mailing lists. Therefore if you are a casual reviewer you can use these triggers to review the new changes without having to keep your finger on the specific pulse of things.
When all changes have been made to the specification and the tech team /editors are in agreement that this sis ready to go, a Best and Final approval notice will be sent to the General List. Note that we generally use Lazy Consensus as defined in our Governance document when approving something.
Specification Review Checklist
| Item | Who is Responsible | Status |
| Notification of start of work on a new version to the General List (with summary) | Tech team lead | |
| Web site updated with page to hold new spec version (points to google doc repro) | Web Site Admin | |
| Web site news announcement (in banner area) that draft is under way | Web Site Admin |
SPDX Specification / Document Collateral Release Checklist
| Item | Who is Responsible | Status |
| Notification on general list that the specification is approved | Tech team lead | |
| Web site updated with page to hold new spec version | Web Site Admin | |
| Web site news announcement (in banner area) that there is a new version | Web Site Admin | |
| Press release (via Linux Foundation) for the new version | Business Team |
