Opened 10 months ago

Closed 3 months ago

#20982 closed defect (wontfix)

Remove trailing dot from version numbers

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Trivial Keywords:
Cc: atagar, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The output of the --version and --library-versions options of tor and the --version option of tor-resolve include a trailing dot. Such commands for other programs typically do not include a trailing dot.

Child Tickets

Attachments (3)

Change History (24)

comment:1 Changed 10 months ago by cypherpunks

Status: newneeds_review

comment:2 Changed 10 months ago by cypherpunks

Looking at the GNU Coding Standards about the --version option it seems to be common to only print the program name and version number without using a version prefix.

Changed 10 months ago by cypherpunks

comment:3 Changed 10 months ago by cypherpunks

Added a patch for removing the version prefix as mentioned in comment:2 and a patch for the changes file.

comment:4 Changed 10 months ago by teor

Milestone: Tor: 0.3.0.x-final
Status: needs_reviewmerge_ready

These changes seem sensible.
Let's get them merged.

comment:5 Changed 10 months ago by nickm

Resolution: fixed
Severity: NormalTrivial
Status: merge_readyclosed

Merging!

comment:6 Changed 10 months ago by nickm

This should *not* be taken to mean that we're committing to follow GNU standards in all things at all times.

comment:7 Changed 10 months ago by nickm

Cc: atagar teor added
Resolution: fixed
Status: closedreopened

It appears this broke the stem integration tests.

comment:8 Changed 10 months ago by nickm

Looks like atagar favors a revert.

Atagar, can you confirm that reverting 78a13df15842e8ab262e17825160386fadb77056 is enough to fix the problem, or should we revert 62f52a888acc191bcb507d27d31d54e42e6effdd too?

comment:9 Changed 10 months ago by atagar

Hi Nick. Stem shouldn't care about commit 78a13df. It's commit 62f52a8 (changing 'Tor version <blah>' to 'Tor <blah>') that breaks stem's get_system_tor_version() since it checks for that prefix...

https://gitweb.torproject.org/stem.git/tree/stem/version.py#n91

I'd be happy to change Stem to be more flexible if you'd like - just tell me what format I should expect that line to be in. However, to avoid breaking folks we'll need to wait until those stem changes have been in a release for quite a while before changing stuff on tor's side (sorry about that!).

comment:10 Changed 10 months ago by atagar

Oh wait, my bad - yes, it checks for the ending period too. :(

comment:11 Changed 10 months ago by cypherpunks

I suggest changing Stem and updating the changes file to mention that Stem users need to update.

comment:12 Changed 10 months ago by atagar

Sorry, unless this is vital to Nick I'm not cutting a special release for just this. If we'd care to change the version output that's fine, but it'll need to be in the future after a new release is out.

Nick: If you'd care to go this route just let me know what you'd like Stem to accept.

comment:13 Changed 10 months ago by nickm

Since this is a cosmetic improvement at best, I'm reverting for now. Breaking compatibility with existing tools is a bit rude, and breaking integration tests is downright risky.

Cypherpunks, is there a benefit to changing stem to accept both formats, and changing Tor later on? That is, is there some other tool that will work better with Tor if we make these changes?

comment:14 in reply to:  13 Changed 10 months ago by cypherpunks

Replying to nickm:

Cypherpunks, is there a benefit to changing stem to accept both formats, and changing Tor later on? That is, is there some other tool that will work better with Tor if we make these changes?

Not AFAIK. I'm okay with reverting since it seems to generate more work than it's worth. You may also close this ticket as wontfix.

comment:15 Changed 10 months ago by teor

For consistency with GETINFO version, and almost every other tor version display (recommended-versions comes to mind), I would recommend that we:

  • document the format of --version in the tor man page, and add a note that the trailing period might be removed in future,
  • ask stem and other tools to update,
  • eventually change tor to remove the trailing period.

Or we could do nothing.

By the way, the trailing period makes much more sense in:
Tor version 0.3.0.0-alpha-dev (git-f08f72d60654f0f9).

comment:16 Changed 10 months ago by nickm

Or we could do nothing.

This seems like a fine option to me, unless there is something that the period actually breaks.

comment:17 Changed 10 months ago by atagar

Hi Nick. This came up with an earlier patch just a week ago. Stem checks for the period in the line.

comment:18 in reply to:  17 Changed 10 months ago by nickm

Replying to atagar:

Hi Nick. This came up with an earlier patch just a week ago. Stem checks for the period in the line.

Err, sorry. I meant, we should do nothing unless there is something that breaks when there is a period. If every relevant tool works with the status quo, then IMO there's not much reason to change.

comment:19 Changed 10 months ago by atagar

Err, sorry.

Bah. No, my bad. Completely misread the earlier comment. Still sipping my morning coffee. :P

comment:20 Changed 10 months ago by nickm

Milestone: Tor: 0.3.0.x-finalTor: unspecified

comment:21 Changed 3 months ago by nickm

Resolution: wontfix
Status: reopenedclosed
Note: See TracTickets for help on using tickets.