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

[Ryan Schmidt]

> On Sep 3, 2016, at 11:49 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> On Saturday September 03 2016 10:57:24 Ryan Schmidt wrote:
> 
>> You mustn't change the version in a variant, because MacPorts decides when a port is outdated based on what's in the portindex, and the portindex only includes one entry for each port, and the version recorded in the portindex for a port is the version that would occur with the default variants that were in effect at the time the portindex was generated 
> 
> Indeed, that's a sufficient reason to avoid this approach.
> 
> The argument doesn't entirely fly though for true legacy variants like Qt 5.3.2 which won't ever change version O:^)

Suppose you hypothetically had a qt5 port with version 5.6.1 but a variant that changed version to 5.3.2. Suppose a user installed this port with that variant. If the user ran "port outdated", MacPorts would tell them the port is outdated because 5.3.2 is less than 5.6.1. If the user tried to upgrade the port, nothing would happen because the port is actually up to date, according to the variant.

So please, stop contemplating the idea of changing the version in a variant. It is not to be done.


>> Actual data would be required to make a decision. If, for example, 5.7 decided to drop support for everything older than El Capitan, I would call that premature and would use that as a reason not to update to 5.7.
> 
> But then you'd condamn all software that depends on 5.7 features.

In this hypothetical scenario, yes, that's true. I have no knowledge of what those features might be or how detrimental omitting them might be.

> Either way, if a variant-based approach is out, the issue becomes less urgent (urgent in the sense that I plan to move my qt5-kde-devel port to 5.7 soon, and would have implement the variant logic straight away). When separate ports are required the decision can be made any time to "fork off" the current 5.6 port(s) (or not).
> 
> R.