Keystone 4 Roadmap and Maintenance

[JedWatson]

For background, Keystone 5 is here and we're very excited about it!

However, it's still in alpha, and we don't have a timeline yet for when it will be a comfortable upgrade for people who've built projects on Keystone 4.

So with the future in mind, this issue is for discussing the present, and how we can all shepherd this version of keystone over the next year and support our users.

My proposed plan is this:

• Keystone 4 will go into "maintenance" mode; no major refactors or new features will be added (including some WIP features that haven't made it into master yet)
• We'll close as many issues and PRs as possible relating to support, feature requests, and things that are out of scope
• I'll be putting in time with any contributors who step up to help shepherd bug fixes or minor additions into v4, and manage releases

I think now that Keystone 5 is open, it's reasonable to say that v4 is "feature complete" - if it works for you, that's great! and where there are bugs or minor issues, they should fixed. But in terms of major changes, the core team's attention is on v5 and it is a much more productive project to build new features in.

Long-term project stability is a major concern for Keystone, so if anyone wants to make major changes to v4 to support their own use-case, I believe the best approach would be to fork the project and publish it independently. Major changes in this codebase carry a large risk of breaking other people's projects, and the priority is to keep Keystone 4 stable for everyone using it. We also won't publish any updates that include breaking changes.

npm makes publishing projects under your own scope trivial (for example, I could publish my own fork to @jedwatson/keystone) and if any forks gain significant new features or benefits I'd be happy to point to them in the readme for any other users who want access to those features.

I also want to point out again that while Keystone 5 is not backwards compatible, as it matures we will do our best to provide a good upgrade path for Keystone 4 users.

Help Wanted

For anyone who can help manage the maintenance of Keystone 4, it would be great if you can join the #v4-maintenance channel on our slack and shout out there.

We'll need help:

• Closing old issues and PRs that won't be merged, in particular ones that add major features
• Identifying meaningful bugs and issues that we should fix, and organising them into a project
• Contributing, triaging and reviewing PRs

Being honest, we've had a few false starts maintaining v4 during the development of v5. I'm hoping that by simplifying the scope and being clearer about the workflow we can get some good momentum here and support our v4 community while v5 matures.

[laurenskling]

Much respect for this post @JedWatson and I think the absolute best step forward. Let's get v4 as bugfree as possible for the people using it right now. I would be happy to help out giving the maintenance mode a fair chance. Limiting the open issues is a good first step, sadly dropping some work, but it has to be done to get v4 forward.

[alexgrant999]

Thanks @JedWatson for the update.. Looking forward to v5!! Would love to have a chat with you:)

[sonyamusk]

Hi Jed, I'm really sorry to bother you, but there is a bug in Keystone 4 that hasn't been fixed since 2018, and it is still in current version Keystone JS 4.2.1. I don't know how to reopen this issue, but if someone could take a look at this and help fix this bug, me and some other people would really appreciate it.

Here it is: #3374