Replies: 4 comments 3 replies
-
I feel the same way but am reluctant to try and impose the extra maintenance burden on @rossabaker |
Beta Was this translation helpful? Give feedback.
-
One reason for going to 0.24 could be that its starts to get increasingly painful to merges. I think @armanbilge and @danicheg can certainly attest to that. Having two increasingly divergent branches is a maintenance burden. Although that is a problem, we have been constantly dropping milestone releases, which users may try. Is main in a releasable state as a 0.24 series now, or do we need to stabilize something? Could we call main as 1.0 and rather focus on a 2.0 with cats-uri and other breaking changes? Why is 1.0 so scary? |
Beta Was this translation helpful? Give feedback.
-
It's a weak justification, but... Joking aside, I am also a little worried that migration |
Beta Was this translation helpful? Give feedback.
-
It's no longer fair to name me specifically for maintenance burden, particularly when I've been a peripheral figure in the last few releases. I'd rather address it as an engineer at a company with seven Scala teams. We're in the midst of an engineering garbage collection pause, where we finally get off cats-effect-2 and friends, including http4s-0.21. Breaking changes are terrible things. Beyond that, there's a significant downstream ecosystem of integrations built on top of 0.23. Every time we introduce a breaking release series as production, that entire ecosystem has to support two, and/or every adopter like my employer hits another GC pause. This is a heavy decision. I don't see any practical difference between labeling a release 0.24.0 and a 1.0.0. It's going to break all the things, and the time we break all the things is:
I don't think the first condition is close to true yet. There's still the transformers so many people hate. There's still the URI, which is the thing people should hate as much as they hate the transformers. There is still the import tax that daunts new users.1 The new entity model is smarter, but unless you want to argue that Techempower isn't horseshit, is it sufficiently better to disrupt every library and user downstream? Now, 1.0 is proceeding at a crawl because we've done such a good job improving 0.23 while stable. To reach those conditions to make 1.0 worthwhile, we could back off enhancements on 0.23 and make it bugfixes only (roughly @danicheg's point above). The branches will diverge further, so each merge may get harder, but fewer merges could lower the overall burden. But we would want:
Footnotes
|
Beta Was this translation helpful? Give feedback.
-
Currently, development of Http4S is done in two branches,
series/0.23
andmain
. The former is being released in the0.23.x
releases, the last one0.23.22
from today, and the first one0.23.0
is from almost two years ago. In the meantime, themain
branch intended to be released as1.0
has been in development for three years since 1.0.0-M1. The current git-diff between the two branches gives a total of 4315 insertions, and 6181 deletions. All of these line changes include binary-incompatible changes inmain
that are not being widely used.Unfortunately, although the
main
branch has been in development, the design of that branch is not completed and there are issues to be addressed. To narrow some of this gap, and to make the improvements inmain
available more generally before the1.0
version is released, there should be a0.24.x
series that includes some binary incompatible changes. In particular, it should include the improvements to theEntity
representation, which improved microbenchmark measurements. It could also include some of the code deletions that are included inmain
.Beta Was this translation helpful? Give feedback.
All reactions