Qt 5.6 LTS vs. 5.7 - should MacPorts provide both and how?

[René J.V. Bertin]

Hi,

You may be aware that Qt have designated v5.6 a long-term support version that will be maintained in parallel to 5.7 (already released) and (probably) beyond.

I still have to look at the exact implications, but this could well put us in a situation where we will need to provide a 5.6 port and a current/latest release version port. In any event it will be necessary to provide a Qt5 port that follows the current/latest release, because that's probably where the real evolution will take place. Qt are usually pretty good at maintaining backward compatibility (even at the ABI level) so it may not be absolutely required to keep a 5.6 release port around, except possibly to ensure compatibility with earlier OS X versions, but again, I have to look into this.

Anyway, how should we approach this? The Qt portfiles are already pretty complicated, the one for port:qt5 probably even more so than mine for port:qt5-kde. However, my port file and directory have already been set up to support multiple versions.

So if we're going to support Qt 5.6LTS and Qt 5.7+, it would be most logical for me to implement this via a +LTS variant. Basically that variant would

- setting a 5.6.x version plus the corresponding checksums (maclhoun's port:qt5 would probably want to put its checksum tables into version-specific files, like I do for the KF5 frameworks)
- maintain an LTS subdir in ${filespath}, for those patches that are different between 5.6.x and 5.7+

The drawback would be that the LTS version will require building from source for everyone. If that's an unacceptable hurdle we'd probably be looking at a separate set of ports with their own port dir because I don't really want to introduce yet more subports to my own port:qt5-kde (and I presume mcalhoun will be equally enthusiastic about the idea).

Using separate ports in their own port dirs *may* be the approach given the least maintenance though, if we presume that 5.6 is going to evolve less (often). Especially since my efforts to make port:qt5-kde and port:qt5 drop-in alternatives using path:-style dependency declarations in the PortGroup have already prepared the way for supporting different versions rather than different build flavours through a single mechanism to declare dependencies on Qt.

R.