[MacPorts] #63979: qca and subports: revisions have not been restored correctly

[MacPorts]

#63979: qca and subports: revisions have not been restored correctly
-------------------------+----------------------
  Reporter:  ryandesign  |      Owner:  RJVB
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  qca         |
-------------------------+----------------------

Comment (by RJVB):

 Replying to [comment:14 RJVB]:
 > Of course there's one difference in this final scenario compared to what
 users of the Qt4 subports will encounter: I actually got to install the
 (fake) new version.


 AAAAHHHHHH

 That's where I think we all went wrong.

 The wrongly upgraded Qt4 subports (`qca` and `qca-*`) actually do build
 and install!! But, since they actually build the same things as the Qt5
 subports (`qca-qt5` and `qca-qt5-*`), they fail in the ''activation''
 stage.

 So my scenario wasn't wrong, the only thing I could have done to make it
 more representative was to activate the real (= non-faked, 2.3.4_1)
 version of the port before trying to "upgrade" to 2.3.4_0+epoch1. But in
 practice that shouldn't have mattered: MacPorts will upgrade regardless of
 which version is active AFAIK.

 Still, it would be nice if there was less ambiguity in how `epoch`
 interacts with downgrades in version and downgrades in `revision`! Even if
 this difference is documented somewhere I don't see why it would exist: to
 me the `revision` scheme is just an additional element to the "native"
 versioning, a "downstream patchlevel" if you want. If `epoch` is intended
 to work as a reset for the versioning scheme it should affect both those
 levels, upstream and downstream.

-- 
Ticket URL: <https://trac.macports.org/ticket/63979#comment:15>
MacPorts <https://www.macports.org/>
Ports system for macOS