> On Oct 14, 2015, at 10:07, Landon J Fuller <[email protected]> wrote: > > > On Oct 14, 2015, at 10:35 AM, Jeremy Huddleston Sequoia > <[email protected]> wrote: > >> >>> On Oct 14, 2015, at 09:21, Landon J Fuller <[email protected]> wrote: >>> >>> >>> On Oct 13, 2015, at 9:16 PM, Jeremy Huddleston Sequoia >>> <[email protected]> wrote: >>>>> If anything, I think MacPorts ought to be shielding users from Apple’s >>>>> use of tooling updates to bitrot working software that happens to not be >>>>> aligned with their release-to-release platform priorities. >>>> >>>> The best way to "shield users" is to fix or remove broken and unmaintained >>>> ports. >>> >>> Unlike post-iOS7 Apple, I don’t think platform vendors serve their users by >>> capriciously breaking working software. >> >> I take great personal offense to that statement. Apple engineers (myself >> included) take great strides to make sure that existing software continues >> to work. Binary compatibility is a top concern at Apple, and if you find >> any case where existing software breaks after an OS update, make sure you >> report it. > > It’s not just binary compatibility (although that in of itself is a serious > problem), it’s also source compatibility. Apple’s constant breaking changes,
Can you enumerate these constant breaking changes please? > keyed to Xcode/SDK versions used — coupled with rapid deprecation and removal > of previous SDKs/toolchains Can you give a specific example of what you believe was done rapidly? OpenSSL was deprecated for about 5 years before its headers were removed from the SDK. That seems like more than enough time for projects to adapt. Additionally, the library still ships, maintaining binary compatibility. > , along with mandatory toolchain updates required to support later releases — > means that existing, working, tagged code, written against purely > stable/public APIs, bitrots in place at a frenetic pace. This is true for pretty much any platform. I challenge you to build gtk1 on a modern Linux distro or qt2 on FreeBSD 10. > Depending on the scale/scope of breaking changes, the cost to keep software > (written to defined APIs!) building and working across iOS (and increasingly > OS X) releases can be unexpectedly large, creating a risk to > maintaining/supporting software on the platform that is quickly outpacing > what we can reasonably justify as a business. We take great pains to ensure that shipped apps continue to work on new OS versions by maintaining binary compatibility. Yes, requirements change (for example, requiring a root view controller in iOS 7), and developers need to adapt to newer requirements, but a TON of effort is made to ensure backwards compatibility. > With open-source projects like PLCrashReporter, I don’t believe there's been > an iOS release since iOS 6 that did not contain serious kernel/dyld > regressions caught by our test suite. You will have absolutely no sympathy from me if you try to use software that takes over the exception handler port. If you do that, you're asking for trouble. I've yet to see an implementation that does this right other than service that Apple already provides to developers to do this for them. > In addition, each Xcode/SDK release has broken the build, requiring that we > take otherwise functioning tagged code and issue an additional release just > for compatibility with the latest Xcode. The amount of churn created by > Apple’s breakneck development pace — coupled with a willingness to break > developers — has reached a point where I’m ready to give up trying to ship > stable releases at all, as there’s little point in providing a “stable” > release that will — at absolute best — break again in the next 6-12 months. >>> If the apple-gcc42 port — or any other — works, then I see no reason to >>> forbid developers from using it. >> >> The port works in that the resulting software does what it was designed to >> do. The problem is that it was designed almost a decade ago. It is an >> antiquated toolchain that is riddled with bugs, won't ever be fixed, and >> doesn't support modern language revisions. > > If it solves someone’s problem — such as building an older port or software — > it still holds value. I don’t think anyone should be obligated to maintain > it, but neither do I think that we need to adopt Apple’s approach of forced > deprecation of things we no longer like. It doesn't have anything to do with liking it or not. It's riddled with bugs, and I see no value in fixing it. > > -landonf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
