Skip to content

VISS Governanance and Release Process

Jump to bottom
Erik Jaegervall edited this page Apr 10, 2024 · 3 revisions

NOTE: Work in progress!

NOTE: Not in any way agreed yet!

How to introduce changes to the specification

Possibly like:

  • Create PR
  • Maintainer announcement (Meeting? Mail? Slack?)
    • Compare to VSS - people generally do not "subscribe" to PRs
    • If substantial - inform DEG/TST to ask for feedback?
    • If not trivial - merge at first 2 weeks after?

Release process

  • First a "code freeze" and a “technical” review period on latest “main” as you described. Possibly request TST to approve it.
  • After that tag latest commit as a release candidate, like “v2.0rc0”, generate PDFs (if we want that as long term release artifacts), create a github pre-release and attach the PDFs. A bit similar to [https://github.com/COVESA/vehicle_signal_specification/releases/tag/v4.1rc0)
  • Then let “someone” approve it. Does TST produce formal protocols – if so they could possibly be the approver. If not – let the board make the final decision after TST has agreed on that it better shall be released
  • After the board has approved it tag with “v2.0” and create the formal github release with the same PDFs.

Notes on Releasing/Tagging

git tag v2.0rc0
git push upstream v2.0rc0
git branch 2.X
git push upstream 2.X
  • Download viss-pdfs.zip form latest build (tag)
  • Unzip
  • Do "Create new release"
  • Use name VISSS <version> like VISS v2.0rc0 or vVISS 2.0 (No third digit unless needed, i.e. 2.0, 2.0.1 usw.)
  • Generate release notes
  • Upload artifacts
  • Mark as pre-release (remove first after approval at meeting)

Creating final release

# Starting from last commit
git tag v2.0
git push upstream v2.0
# Make sure to move the maintenance branch to point to last commit
# Possibly like below
git checkout 2.X
git reset --hard main
git push -f upstream 2.X
Clone this wiki locally