I’m curious if you’ve revisited the NDA recently, since a skim of the verbiage makes it seem to me that discussing the new OSes should be OK, assuming we don’t review it or post screenshots. From https://developer.apple.com/support/terms/apple-developer-program-license-agreement/#ADPLA9.1:
> Further, Apple agrees that You will not be bound by the foregoing > confidentiality terms with regard to technical information about pre-release > Apple Software and services disclosed by Apple at WWDC (Apple’s Worldwide > Developers Conference), except that You may not post screenshots of, write > public reviews of, or redistribute any pre-release Apple Software, Apple > Services or hardware. IANAL and all, but this clause is fairly new and if you haven’t re-evaluated that policy for a while it might be worth doing so again. Saagar Jha > On Sep 21, 2023, at 01:36, Ryan Schmidt <[email protected]> wrote: > > On Sep 21, 2023, at 00:26, Bryan Jones wrote: >> >> Dear MacPorts: >> >> I write to propose a policy change: a MacPorts release for a new macOS major >> version should be publicly available by the time Apple publishes the final >> Release Candidate version of macOS. >> >> Rationale: MacPorts is an annual problem for me. I’m a Mac developer who >> needs to install beta versions of macOS for testing my apps. But once I do >> that, I can’t use MacPorts to build dependencies. Even if I install the >> macOS betas on a clean partition, I *need* MacPorts to re-build those >> dependencies (or I have to switch back to an older partition and copy the >> files manually into /opt/, etc.) >> >> The lag between the release of a new major macOS version and the release of >> a supported MacPorts version should be eliminated. MacPorts is a key part of >> the development environment and each year it essentially goes AWOL just when >> developers need it most: when we’re updating apps to support the new macOS >> release! No one expects MacPorts to be ready when the first beta comes out. >> But there are five months between the first beta and the release of macOS, >> which seems like enough time to at least have an “RC” version of MacPorts >> ready for developers. >> >> Thank you. > > Hi Brian. There are a number of pieces to supporting a new macOS version in > MacPorts. I didn't quite follow the problem you were reporting (you said you > "can't use MacPorts to build dependencies" but didn't say why) so I'm not > 100% sure which of these pieces you're talking about, so let me say some > things which may or may not already be obvious to you and you can reply to > whichever of these you're concerned about. > > You should be able to install MacPorts on macOS Sonoma right now, as you > could at any time since the first beta was released. There is no MacPorts > installer package for Sonoma yet so you would have to build it from source. > Instructions are in the documentation. You can try both building the current > version, 2.8.1, and the latest code in the git master. > > You can then test whether MacPorts works on Sonoma. I don't think we've > received any reports of it not working, but if it doesn't work, and you know > the fix, you can submit a pull request. If you don't know the fix and want to > report it somewhere, then the issue is that pre-release versions of macOS are > made available to you under an NDA, so you shouldn't file a public bug > report, but should discuss the bug privately with others who have agreed to > that NDA. The list of those people is in the wiki. Maybe one of them can fix > the problem. > > Eventually, once we believe MacPorts works on Sonoma, hopefully not long > after the public release of Sonoma, Josh will create an installer package. If > MacPorts 2.8.1 works on Sonoma, he'll make an installer package of 2.8.1 for > Sonoma; otherwise, fixes will have to be committed to macports-base first and > then he'll release MacPorts 2.8.2 for all OS versions. Making the Sonoma > installer package would require that Josh have access to a machine that can > run Sonoma. I don't know if he has that. > > There are some server-side components to new macOS version support as well. > The master build server generates portindexes for each OS version. I already > added macOS 14 to that list two months ago, so portindexes for Sonoma have > been available for awhile. Had I not done that, you would still be able to > use MacPorts on Sonoma, you would just be generating the portindex locally, > which due to the large number of ports we now have in our collection can take > several dozen minutes. > > I need to set up build machines for Sonoma on x86_64 and arm64. Until I do > that, installing any port will build it from source on your system. It > typically takes several weeks to do the initial builds of all ports on a new > macOS version. Of course, many of those builds might fail, depending on what > Apple changed in the new OS. It will take time for any interested members of > the community to notice, investigate, and fix such problems. > > For arm64, we have only one Apple Silicon Mac mini donated to us by Mac > Stadium that switches between macOS 11, 12, and 13, and the disk is full; > there is no room to add macOS 14. I could eliminate the macOS 11 environment > and replace it with macOS 14. Or I could ask Mac Stadium if there is a way to > swap our machine for one with a bigger disk. Or I could follow up with > another party who has offered MacPorts the use of another Apple Silicon Mac > mini. > > For x86_64, I don't have any hardware that can officially run Sonoma (or > Ventura). The hardware I have that runs Ventura unofficially may run Sonoma > unofficially as well, but it will depend on the OpenCore Legacy Patcher > project releasing a Sonoma-compatible version which they anticipate will > happen at an unspecified time later this year. Or I would have to get a > supported Mac, like a 2018 Mac mini. If I did that, I would probably use it > for Ventura builds as well. Possibly, either Mac Stadium or the other party > would be able to offer a 2018 Mac mini instead of an Apple Silicon Mac mini.
