Re: Should we split the project into two branches?

[Andreas Fink]

Question:
is it time to start working on libobjc3 with Swift support and support
for all platforms we want to support?
(if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).

Apple will run away in a decade with Swift only. So if our goal is to
keep OS X compatibility, then we have to think long term on how we think
we want to continue

I would thus suggest to make a list of pro & cons of the current
situation. Especially I want to know

a) which platforms are supported today with gcc and the old runtime
b) which platforms are supported today with gcc and libobjc2
c) which platforms are supported today with clang and the old runtime
d) which platforms are supported today with clang and libobjc2
e) which platforms do we want to support in the future.

I personally have no problem to drop MIPS as I never used it. Others
might have a different view.
Having gnustep-base in embedded systems without GUI might be useful.
But do they need all the new features we plan to add? Might it be better
to move that part to a "classic" release for historic systems?
I would like to see support for RISC-V as I see a lot of future growth
there.

I think its time to do a reality check to figure out commonly on where
we do want to see GNUStep in the future. What should it accomplish and
what are the pro's and cons of each.
Only if such facts are on the table, one can decide on a roadmap.


Max Chan wrote on 15.02.22 00:28:
>
>> 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.