Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defragment Play #195

Open
octonato opened this issue Nov 24, 2021 · 0 comments
Open

Defragment Play #195

octonato opened this issue Nov 24, 2021 · 0 comments

Comments

@octonato
Copy link
Contributor

There are many things we have discussed at Lightbend that could reduce the maintenance of Play. I believe they are now much more pressing because with a reduced team and resources we don't want our time to be wasted.

On major source of friction is the fact that Play was fragmented in so many small libraries. The fact that we needed something like Interplay and Omnidoc is actually a symptom of this fragmentation.

To illustrate it, we need to keep track which Interplay is used on each of the different project/branches. For example, playframwork/2.8.x use interplay/2.1.x. So to release Play we must first check if we have a recent release of interplay (from the 2.1.x branch) and so forth.

Regarding interplay, we have already consensus and we started to move out of it (playframework/interplay#150).

But it doesn't stop there. Before releasing Play, we need to check if we need a release of play-json, twirl and play-ws. And then we are again in the dance of checking which branch needs to be released. Release the branch, update Play and then release Play. And then again update Omnidoc and release Omnidoc.

I would suggest that we integrate back those three libraries into Play repo. They should still produce their own artifacts and users should still be able to use them in separation, but there is no need for us to have to deal with all the complexity of managing them as separated projects.

This is something that we should consider at least for play-json and twirl. For play-ws, maybe it's worth consider if it still make sense to have it around. There are some very good alternative both in the Scala and Java world that we could recommend instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant