Opened 2 years ago

Last modified 3 days ago

#21454 assigned 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:

Description

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
...
MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers
...
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 (10)

comment:1 Changed 2 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 "0.3.1.4-alpha": 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:

  CMP(major);
  CMP(minor);
  CMP(micro);
  CMP(status);
  CMP(patchlevel);

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 2 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 2 years ago by nickm

Parent ID: #21449

comment:4 Changed 22 months ago by nickm

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

comment:5 Changed 17 months ago by nickm

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

comment:6 Changed 17 months ago by nickm

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

comment:7 Changed 15 months ago by nickm

Keywords: 034-triage-20180328 added

comment:8 Changed 15 months ago by nickm

Keywords: 034-removed-20180328 added

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

comment:9 Changed 15 months 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 3 days 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.

Note: See TracTickets for help on using tickets.