100% no, it would not. Unilaterally renaming hidden services is not going to happen.

Trac:
Milestone: N/A to Tor: 0.2.9.x-final

Out of any reasonable milestone for now. Once we decide if good or not, we can set a goal that makes sense.

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???
Severity: N/A to Normal
Reviewer: N/A to N/A
Sponsor: N/A to None

Change Core Tor tickets with sponsor "None" to "", per our practice elsewhere. This will help sorting.

Trac:
Sponsor: None to N/A

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: tor-hs deleted, tor-hs prop224? torrc added

legacy/trac#25918 (moved) is an umbrella ticket for the entire rename

Trac:
Parent: N/A to legacy/trac#25918 (moved)

//Minor//: prop224-maybe seems like a better convention for the keyword

Trac:
Keywords: tor-hs prop224? torrc deleted, tor-hs prop224-maybe torrc added
Cc: N/A to dmr

HiddenService* --> OnionService*

Currently: HiddenServiceVersion 3 HiddenService...

New: OnionService...

(automatically set version to 3)

Replying to cypherpunks:

HiddenService* --> OnionService*

Currently: HiddenServiceVersion 3 HiddenService...

New: OnionService...

(automatically set version to 3)

No, aliases should mean exactly the same thing: anything else is confusing to users.

We have missed the opportunity to link the OnionService transition to version 3 onion services, because they came out in 0.3.2, which is stable and won't be getting new features or new options. (I don't know if we would make an exception for aliases.)

I'm okay with backporting aliases.

Trac:
Cc: dmr to dmr, s7r