Re: Should we split the project into two branches?

[Richard Frith-Macdonald]

> On 15 Feb 2022, at 08:13, Max Chan <xcvista@me.com> wrote:
> 
> 
> 
>> On Feb 15, 2022, at 2:54 AM, H. Nikolaus Schaller <hns@computer.org> wrote:
>> 
>>> Am 15.02.2022 um 08:36 schrieb Max Chan <xcvista@me.com>:
>>> 
>>> Come to think of it, if we do chase the latest feature especially Swift 
>>> compatibility, we get Swift Package Manager along with it which can be used 
>>> as a parallel build system bypassing gnustep-make.
>> 
>> Hm. To me it looks as two distinct projects. GNUstep and some Swift 
>> compatible thing (however it is called) using a different build system.
>> IMHO it is no problem hosting such elsewhere and from time to time 
>> cherry-picking components from GNUstep and vice versa.
>> It is the way my project mySTEP is run. Separate repositories and mutual 
>> exchange where it makes sense.
>> 
> 
> What I mean here is, using the parallel build scripts approach, core 
> libraries like base and gui can allow features written with new features like 
> ARC, Blocks and XPC to enter without affecting legacy support.
> The legacy build script is not even aware of the existence of those new 
> features which they can not support, while if you want to build those 
> features you need the new build environment which guarantees the support of 
> those.

My problem with this thread is that you keep writing things about GNUstep which 
are categorically false.

The current build system supports ARC and conditionally building clang specific 
code etc, and as far as allowing 'features written with new features like ARC, 
Blocks and XPC to enter without affecting legacy support.'  goes, such things 
have already entered GNUstep.
Contributors to GNUstep have spent their time and effort in making sure that it 
supports all this range of stuff in an easy to use and flexible manner, so 
false claims that all this stuff doesn't exist seem insulting to those 
contributors.

I think this thread should be called to a close since it is based on a false 
premise.  Conclusions and inferences from false premises are usually incorrect, 
and certainly need reevaluation before it makes sense to discuss them.

Why not try implementing some new feature Apple has added recently, to see what 
problems there *really* are, and ask how to overcome them?