Should we split the project into two branches?

[Max Chan]

Dear List,

There are over and over again arguments on moving on to LLVM/clang for latest 
language features versus maintaining compatibility with old/uncommon platforms 
and GCC, to the point that IMO we are so far behind on language feature parity 
with Apple releases. With the most glaring hole that is Swift compatibility 
language support.

The idea here is to take a similar approach as Fedora versus RHEL - one branch, 
GNUstep-Next, chases the latest features and only mind making them work on the 
most common targets; while the other branch, mainline GNUstep, takes snapshot 
codebases from the Next branch and work in compatibility with other less common 
platforms and maintain ties with GCC. This will shed folks working on the Next 
branch off a lot of legacy and political baggages.

For the Next branch, IMO we only need to mind four targets: Linux-amd64, 
Linux-aarch64, Windows-amd64 and Windows-aarch64. The Next branch can straight 
up require LLVM/clang and libobjc2 to build. The Next branch can freely use all 
features afforded in the Objective-C 2.5*. A major goal for Next would be Swift 
compatibility. Either we can piggybacking on Apple’s release, or we can ship a 
snapshot of Apple’s Apache-2.0 code in the Next branch with all necessary 
patches to enable Swift-ObjC interoperability. Then it is implementing all 
macOS/iOS frameworks we currently does not have a reimplementation of, with the 
big ones being UIKit and SwiftUI.

As of the build system, especially if the Next branch can bring in Swift 
support, we can drop gnustep-make and make everything that is not gnustep-base, 
libobjc2 and libswift build using Swift Package Manager. (SPM depends on 
command line Swift. For us to provide command line Swift support, we need a 
LLVM/clang based compiler, libobjc2, libswift and Foundation aka gnustep-base.) 
We may need to extend our branch of SPM to allow building Objective-C and 
Objective-C++ packages though. Packages like gnustep-gui will lose all its 
Makefiles and gain a Package.swift file instead.

Sincerely,
Max Chan

* Since Objective-C is only getting language features now because of Swift, we 
might as well call it Objective-C version 2.{Swift version}. Objective-C 2.5 
means Objective-C 2 with all features introduced as of the release of Swift 5. 
In that sense, the latest version of Objective-C is 2.5.5.3 corresponding to 
Swift 5.5.3

signature.asc
Description: Message signed with OpenPGP