How many branches do we currently have? When coming to merging, I am okay if those two branches never truly merge. The mainline branch basically stays in line with Mac OS X 10.6.8, conveniently the last release of macOS with GCC support from Apple as well. While the Next branch chases the latest macOS and iOS releases. Since the Next branch is spearheading with features while the mainline focuses on compatibility and stability, we can take the Fedora/RHEL approach - mainline branch takes periodic snapshots of the Next branch, then try to backport everything added in the Next branch. Next branch should allow new features like ARC and syntactic sugars being used even in the core to speed up development and attract young contributors so we can chase the actively developed target that is latest macOS with maximum efficiency, and the backport process downgrades the code to the decade-old version of the language to maximize compatibility. Once the GCC folks got their s#!t together and implemented all those new ObjC features, we can then drop the 10.6.8 based code and have the mainline branch focusing on simply adding platform support to snapshots of Next.
It is likely mainline and Next would be using two very different ABIs (mainline will stick to libobjc and libobjc2 ABI, while Next branch is likely going to end up using the ABI Apple is using for their Swift releases.) It may be a good idea to call the Next branch something like “GNUstep with Swift,” since that is likely the biggest feature we need to chase for IMO, at the cost of compatibility to some less than common targets if necessary. Then we can simply say something like “if your project currently targets a version of macOS after the release of Swift, even if you only uses Objective-C, use the new branch with Swift support.” Mac OS X 10.6.8 conveniently predates Swift for that matter. > On Feb 14, 2022, at 4:08 PM, Gregory Casamento <greg.casame...@gmail.com> > wrote: > > Having so many branches will confuse things greatly. I am not sure it's a > good idea to split the project like this. Also, with many branches > divergence becomes a greater possibility which might complicate merging. > > On Mon, Feb 14, 2022 at 3:11 PM Max Chan <xcvi...@me.com > <mailto:xcvi...@me.com>> wrote: > > > > On Feb 14, 2022, at 12:39 PM, Andreas Fink <af...@list.fink.org > > <mailto:af...@list.fink.org>> wrote: > > > > > > > > Richard Frith-Macdonald wrote on 14.02.22 17:43: > >> > >>> On 14 Feb 2022, at 14:59, Max Chan <xcvi...@me.com > >>> <mailto:xcvi...@me.com>> wrote: > >>> > >>> > >>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald > >>>> <rich...@frithmacdonald.me.uk <mailto:rich...@frithmacdonald.me.uk>> > >>>> wrote: > >>>> > >>>> > >>>> > >>>>> On 14 Feb 2022, at 11:43, Max Chan <xcvi...@me.com > >>>>> <mailto:xcvi...@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, > >> Please don't spread such nonsense on the mailing lists. > >> > >> The fact that we have a huge base of code that builds with both GCC and > >> clang (and a small part that only functions when built with clang) in no > >> way restricts us in the way we write new code. > >> > >> Having highly portable code is a strong point, but that doesn't mean that > >> *all* features are equally portable or that contributors are required to > >> write perfect portable code. > >> > >> It does the project a huge disservice to tell developers they 'have to use > >> an ancient version of the language'. Please don't do it. > > > > It does the project a huge reality check to tell developers they 'have to > > use an ancient version of the language *IF THEY WANT TO CONTRIBUTE TO > > GNUSTEP*'. > > That's says it all. > > That is kind of my point. The mainline branch focuses on maintaining the > highly portable codebase, while the Next branch focuses on features and > library support, free to break compatibility with anything that is less than > popular in the wild. The popular targets IMO are Linux-amd64, Windows-amd64 > and Linux-aarch64, maybe Linux-armv7. > > I wished we could support Swift language and Swift-ObjC interoperability, but > that will likely require a major refactor to libobjc2, base and corebase, and > maybe even a new ABI. Those are the core parts of GNUStep where compatibility > is of the utmost importance, but Swift compatibility is likely going to end > up requiring breaking changes. Swift interoperability brings in Swift Package > Manager, which can be a modern replacement for gnustep-make. That change to > the build system likely will also break compatibility. > > Also, if we are willing to accept breaking changes even just on a branch, we > may even start incorporating Apple’s Apache-2.0 code in this project, taking > bits and pieces from that open source release of Swift language. For example > AFAIK there is an Objective-C runtime core in libswift that is both ObjC 2.0 > compliant and very performant, which may even be a fork of the version of > libobjc Apple used in macOS and iOS, maybe we can just nab that to make our > libobjc2 more performant. > > > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org <http://www.gnustep.org/> - > http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/> > https://www.patreon.com/bePatron?u=352392 > <https://www.patreon.com/bePatron?u=352392> - Become a Patron > https://gf.me/u/x8m3sx <https://gf.me/u/x8m3sx> - My GNUstep GoFundMe > https://teespring.com/stores/gnustep <https://teespring.com/stores/gnustep> - > Store
signature.asc
Description: Message signed with OpenPGP
