If they feel that they would have to support process model even after migration to threaded one, I think the change should be done in a fork. Less maintenance and problems with backward compatibility, and hopefully with time the new approach will get enough traction to turn off the lights in the old one.
this post was submitted on 19 Jun 2023
14 points (100.0% liked)
Technology
35121 readers
12 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
It strikes me that this is the sort of situation where developers interested in this architectural change should fork Postgress to a new project instead of redirecting the development of Postgress altogether.
where developers interested in this architectural change
According to the article, no one really disagreed with it at a high level. Obviously the details of how to get there are going to be relatively complicated and different people will probably have different ideas about the best approach to use.
should fork Postgress to a new project instead of redirecting the development of Postgress altogether.
Did you read the article? Basically the point is the world has moved on and the existing approach is outdated and starting to show its age and limitations.
Forking and making a new project is basically saying Postgres is obsolete and will stay obsolete. Assuming people can generally agree that changes are needed to stay relevant, updating the existing project to keep up with the times seems like a better approach to me.
It's the same way a lot of web servers (and just daemons in general) used to use a forking model but eventually either died or transitioned to using IO multiplexing. The fork based approach just became obsolete, and projects had to adapt or get replaced.