-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
andplay-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
andtwirl
. Forplay-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.The text was updated successfully, but these errors were encountered: