Re: Should we split the project into two branches?

[Max Chan]

> On Feb 14, 2022, at 6:06 PM, Riccardo Mottola <riccardo.mottola@libero.it> 
> wrote:
> 
> I continue to think that a restriction into core libraries is
> acceptable, if it leaves the freedom for your "app code" (or... other
> code you need of course).
> 

The problem is that our core libraries are dreadfully outdated. It is on par 
with Mac OS X 10.6.8, which is a decade old now. This whole Next branch idea is 
to remove the restriction on the new branch so people interested in or need new 
features can chase the latest features, a big one being Swift interoperability, 
and leave the tasks of restoring compatibility to the main branch as an 
“afterthought.”

> 
> PS: indeed I think there is no servce in continuing to denigrate our own
> project, including menacing splits or fork. It was my first thought too,
> but I hope it can be avoided, by a single solution with options or
> configurations.
> 

IMO it can eventually be done especially after we bring in Swift support, as 
that gives us two parallel build systems, one of which has a hard dependency on 
the new features. For people needs legacy support they can still use 
gnustep-make and the makefiles; while people using new features skip 
gnustep-make entirely and use Swift Package Manager instead. SPM hard depends 
on Swift, which is one of the new language features I consider worth breaking 
compatibility for.

signature.asc
Description: Message signed with OpenPGP