Preparing for 2.6.0 beta

[Mojca Miklavec]

On Sat, 24 Aug 2019 at 16:40, Ryan Schmidt wrote:
> On Aug 24, 2019, at 08:55, Joshua Root wrote:
> > On 2019-8-24 21:59 , Mojca Miklavec wrote:
> >
> >> I would be grateful for addressing these:
> >>
> >> https://trac.macports.org/ticket/50448
> >
> > Way too late to do anything about that in base. The plan is as described
> > in comment 16.
>
> I didn't realize that was the plan we had settled on, but I haven't been following MacPorts developments that closely this year.
>
> I saw the commits from you to base, changing the default stdlib to libc++ on 10.6-10.8. Looks like your proposal is for users to run rev-upgrade after upgrading.
>
> What is the plan for the buildbot and our prebuilt archives? Obviously we would need to rebuild all of the archives for C++ software on 10.6-10.8. Since you are not planning on changing the archive filenames or their location on the packages server, and since the buildbot uses the presence of the archives on the packages server as an indicator that the ports have already been built, the buildbot will not know that it should rebuild them. I imagine we will have to manually identify all the ports that use C++, remove their archives from the packages server, uninstall them on the 10.6-10.8 buildbot workers, and then trigger new builds for them.

Would it be possible to set up at least one builder with 10.6 running
MacPorts master, building all ports with libc++ (apparently default by
now in master), just not uploading the archives to the public site, or
potentially uploading them to a 10.6 subfolder? That is, instead of
putting the file under
    http://packages.macports.org/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
we would put it under
    http://packages.macports.org/10.6/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
or something else than 10.6 (darwin10.x86_64, 10.6.x86_64, ...).

That way we could at least have all the packages ready by the time
when we do the switch.

A few years back Ryan's biggest opposition to introducing subfolders
with macOS version was the ability to get a quick overview of macOS
versions where the port built successfully. With the new app I believe
this is no longer of any concern.

Independent from the stdlibc++ vs. libc++ question I still believe
that it would be really nice to be able to easily include/exclude the
set of macOS versions. Say that we organize the meeting with very poor
internet connectivity (which incidentally seems to be the case this
October). It comes really handy if we can bring a mirror of all files,
but excluding the platforms we are sure we won't be needing. Sure
that's also possible to do by filtering out certain filenames, but
being able to just skip some folders is much easier.

Mojca