Opened 3 years ago

Last modified 6 months ago

#21454 new defect

tor_version_compare and version spec comparison order are inconsistent

Reported by: teor Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-spec, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: #21449 Points: 1
Reviewer: Sponsor:


Similar to #21449, when we compare versions, we compare the status before the patchlevel, and then compare status tag and SCM information.

But the spec says:

1. The Old Way
We compare the elements in order (major, minor, micro, status, patchlevel, cvs)
2. The New Way
All versions should be distinguishable purely by those four numbers.

The STATUS_TAG is purely informational
If we *do* encounter two versions that differ only by status tag, we compare them lexically

This doesn't matter much at the moment because we don't use patchlevels.

But we should fix this issue, probably by modifying the spec.

Reported by arma.

Child Tickets

Change History (11)

comment:1 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Owner: set to nickm
Status: newaccepted

We do use "patchlevels" in current version numbers, as in "": Major is 0, Minor is 3, Micro is 1, and patchlevel is 4. This format is as described in "the new way" in version-spec.txt: MAJOR.MINOR.MICRO[.PATCHLEVEL][-STATUS_TAG][ (EXTRA_INFO)]

Now, in tor_version_compare, we do:


But it's the "status" field we no longer use in version numbers, not the "patchlevel" field. "Status" was used for representing the "pre" or "rc" in 0.0.8pre5.

comment:2 Changed 3 years ago by nickm

I have a torspec branch version_grammar that tries to specify a grammar that actually matches what we parse. But it's a little wrong and ugly, and it doesn't explain how we really compare yet.

I wonder if simplifying the behavior here isn't a better answer

comment:3 Changed 3 years ago by nickm

Parent ID: #21449

comment:4 Changed 3 years ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final
Priority: MediumLow

comment:5 Changed 3 years ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.5.x-final

comment:6 Changed 3 years ago by nickm

Milestone: Tor: 0.3.5.x-finalTor: 0.3.4.x-final

comment:7 Changed 2 years ago by nickm

Keywords: 034-triage-20180328 added

comment:8 Changed 2 years ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:9 Changed 2 years ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:10 Changed 14 months ago by nickm

Owner: nickm deleted
Status: acceptedassigned

These tickets are not things I'm currently working on. They may be important, but they don't need to be done by me specifically. Un-assigning.

comment:11 Changed 6 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.