Opened 6 years ago

Closed 6 years ago

#12586 closed defect (fixed)

Specify versioning scheme in Ooni Release-Procedure.md

Reported by: nathan-at-least Owned by: hellais
Priority: Medium Milestone:
Component: Archived/Ooni Version:
Severity: Keywords: versioning release packaging
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The current release procedure for Ooni would benefit from describing the versioning scheme. This should serve two purposes:

  • users can make decisions about installation and upgrade. For example, they may choose to *not install* a new release if they prefer to only upgrade to security fixes or "stable" releases.
  • if a new Ooni dev comes along and makes a new release, they will not violate the expectations of users.

Keep in mind there are at least two categories of "user": probe operators and backend service providers.

As a bonus, the versioning scheme should also be described in each package's own documentation, or perhaps those docs should link to a single source of truth in the spec repository.

Child Tickets

Change History (2)

comment:1 Changed 6 years ago by hellais

Status: newneeds_review

I updated the release procedure document to include details about this. It now also contains many more details on which automated and manual testing tasks should be done before creating a new release.

Feedback on this would be very appreciated:

https://github.com/TheTorProject/ooni-spec/blob/master/Release-Procedure.md

comment:2 Changed 6 years ago by hellais

Resolution: fixed
Status: needs_reviewclosed

Since now feedback was provided I am going to consider this done.

Note: See TracTickets for help on using tickets.