Re: Should we split the project into two branches?

[Max Chan]

> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald 
> <richard@frithmacdonald.me.uk> wrote:
> 
> 
> 
>> On 14 Feb 2022, at 11:43, Max Chan <xcvista@me.com> wrote:
>> 
>> 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,
> 
> Really this is simply not the case among GNUstep developers.
> Those of us who actually use the stuff just work with whatever we 
> prefer/need, because GNUstep already works with both toolchains.

The hard requirement of allowing building using GCC means we are restricted to 
language features equivalent of OS X 10.6.8 or iOS 4.3.5, that is more than a 
decade old. How can you convince young developers to come work on a project, 
which they have to use an ancient version of the language? Keep in mind 
Objective-C 2 has evolved fairly rapidly since Swift became a thing.

Branching the project means the new branch can shed some historic baggages. 
Instead of keeping compatibility with existing GNUstep-specific code, the goal 
of the new branch is to allow a new macOS-targeting project to be ported over 
with minimal effort. The new branch can break support for any platform that is 
less than popular in the wild. The new branch can hard require LLVM/clang and 
libobjc2. The new branch can use all language features introduced since OS X 
10.6.8 including and ARC even in core parts of the project. The new branch can 
do some major refactoring to make GNUstep library structure align better with 
Apple’s current structure. The new branch can even use a different ABI (which 
may be required if we want to do anything with Swift.)

signature.asc
Description: Message signed with OpenPGP