Opened 3 years ago

Closed 2 years ago

#21141 closed defect (fixed)

Come up with a more uniform versioning scheme for versions between releases

Reported by: karsten Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I realized that we're using different -dev version strings in metrics-lib and CollecTor/Onionoo.

Here's what we did in metrics-lib:

dd4b395 Bump version to 1.5.0-dev.
fb74059 Prepare for 1.5.0 release.
38b18e3 Bump version to 1.4.0-dev.
adf4a67 Prepare for 1.4.0 release.
c68b090 Bump version to 1.3.1-dev.
ec268b5 Prepare for 1.3.1 release.
ad9a106 Bump version to 1.3.0-dev.
9195a7c Prepare for 1.3.0 release.
fecd53b Bump version to 1.2.0-dev.
7e58458 Prepare for 1.2.0 release.
8767f3e Bump version to 1.1.0-dev.
d5f89d1 Prepare for 1.1.0 release.
f8f2c1b Bump version to 1.0.0-dev.
c54b816 Prepare for 1.0.0 release.

I believe this is a good scheme, because it produces version strings that can be lexicographically sorted in the correct order. For example, 1.0.0 < 1.0.0-dev < 1.1.0.

And here's what we did in CollecTor and Onionoo (annotated with version strings we should have used instead):

48ef37a Bump version to 1.1.2-dev.                 # 1.1.1-dev
1510b0d Prepare for 1.1.1 release.
dcec864 Bump version to 1.2.0-dev.                 # 1.1.0-dev
d9e32d5 Prepare for 1.1.0 release.
4f15d88 Bump version to 1.1.0-dev, yet once more.  # 1.0.2-dev
c43d0ad Prepare for 1.0.2 release.
7ae84f2 Bump version to 1.1.0-dev, once more.      # 1.0.1-dev
fc3e12e Prepare for 1.0.1 release.
8393774 Bump version to 1.1.0-dev.                 # 1.0.0-dev
06bcf32 Prepare for 1.0.0 release.

b1e96fe Bump version to 3.1-1.0.1-dev.             # 3.1-1.0.0-dev
1eff62e Prepare for 3.1-1.0.0 release.

How about we start using version strings following those annotations from now on?

And should we document this somewhere?

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by iwakeh

Yes, I prefer the metrics-lib versioning, too! In addition, it avoids predicting the next versioning jump.

Good question about documentation. Currently, this is just known and here and there agreed upon, but not documented. New wiki page?

comment:2 Changed 3 years ago by karsten

Great! I'll update CollecTor and Onionoo dev versions accordingly.

Regarding documentation, here's where metrics-lib's versioning scheme is currently documented, though that's not necessarily the best place:

https://gitweb.torproject.org/metrics-lib.git/tree/CONTRIB.md#n243

comment:3 Changed 3 years ago by karsten

(Updated version strings in CollecTor and Onionoo.)

comment:4 Changed 2 years ago by karsten

Resolution: fixed
Status: newclosed

We have been using the new schema for at least 8 months now, so I hereby declare it institutional knowledge. We could of course document it on the wiki, but we could document many more things there, and this particular part doesn't require us to keep this ticket open. Closing.

Note: See TracTickets for help on using tickets.