Remove trailing dot from version numbers

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.

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified priority::medium resolution::wontfix severity::trivial status::closed type::defect labels

Trac:
0001-Remove-the-trailing-dot-from-version-numbers.patch

Trac:
Status: new to needs_review

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.

Trac:
0002-Remove-the-version-prefix-from-version-numbers.patch

Trac:
0003-Add-a-changes-file-for-ticket-20982.patch

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

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

Trac:
Status: needs_review to merge_ready
Milestone: N/A to Tor: 0.3.0.x-final

Merging!

Trac:
Resolution: N/A to fixed
Severity: Normal to Trivial
Status: merge_ready to closed

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

It appears this broke the stem integration tests.

Trac:
Cc: N/A to atagar, teor
Resolution: fixed to N/A
Status: closed to reopened

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?

Hi Nick. Stem shouldn't care about commit 78a13df. It's commit 62f52a8 (changing 'Tor version ' to 'Tor ') 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!).

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

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

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.

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?

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.

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).

Or we could do nothing.

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

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

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.

Err, sorry.

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

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: unspecified

Trac:
Status: reopened to closed
Resolution: N/A to wontfix

closed

mentioned in issue #22110 (moved)

moved to tpo/core/tor#20982 (closed)