> On Sep 3, 2016, at 5:45 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
>
> 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.
I am inclined to say we don't need to keep 5.6 after upgrading the ports to 5.7.
In any case, using a variant to provide it is not an option. A variant shall
not change the version field.
You mentioned support for older OS. What is the minimum OS version for 5.7, vs
5.6?
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
