Open Geod24 opened 3 weeks ago
github-actions[bot]
commented
3 weeks ago BUILD FAILED
❌ Basic dub build failed! Please check your changes again.
Build statistics:
statistics (-before, +after)
executable size=5259464 bin/dub
-rough build time=64s
+rough build time=4s
Geod24
commented
3 weeks ago This will definitely require a 2.0.0 version bump!
So we don't follow standard D policy of 10 releases ? It feels odd to have a stronger policy than the compiler. I get your point, and it's the correct thing to do, I don't know if it's the right one though.
In general, as a user, I absolutely hate this kind of light-hearted process for cleaning up/changing APIs that prioritizes minimal improvements on the library side over the constant need to follow these changes throughout the user base
I get that point, and we've definitely been guilty of doing this a bit too much in D. In the case of Dub, there was a lot of exploration needed to narrow down the scope of what the tool was doing. My favorite example was turning Dependency into a discriminated union: before that work, it was not possible to assess the fitness of an API. Dub.fetch(string, Dependency) was the most used API, but obviously it is too broad and that had to be reworked. Using the more user-friendly approach would probably have had an enormous upfront cost and not yielded as good a result. Note that I used what I consider a good middle ground: I did incremental changes locally, and when I was confident enough I was going in the right direction, I submitted a flurry of PR with small changes.
Note that if we want to cut a v2.0 release, I can prepare that, but I would like some more changes in then.
s-ludwig
commented
3 weeks ago So we don't follow standard D policy of 10 releases ? It feels odd to have a stronger policy than the compiler. I get your point, and it's the correct thing to do, I don't know if it's the right one though.
We can follow the same time line, just the version scheme is defined as SemVer and should be treated accordingly.
Using the more user-friendly approach would probably have had an enormous upfront cost and not yielded as good a result.
Yes, there is definitely a trade-off and many of the changes here are not problematic anyway.
Note that if we want to cut a v2.0 release, I can prepare that, but I would like some more changes in then.
Definitely makes sense to collect as many breaking changes as possible, as long as it doesn't add considerable amounts of additional development costs. I wouldn't necessarily treat this like you would treat a typical product version (i.e. the new shiny version two is out!), but simply as an incremental change that collects a bunch of breaking changes to avoid too frequent breakage.
Geod24
commented
2 weeks ago We can follow the same time line, just the version scheme is defined as SemVer and should be treated accordingly.
To me it doesn't really make sense though, as the release would not remove all the deprecated code, just some. So I'd rather delay things if that's the case (although removing overrides will simplify things quite a lot).
I wouldn't necessarily treat this like you would treat a typical product version (i.e. the new shiny version two is out!), but simply as an incremental change that collects a bunch of breaking changes to avoid too frequent breakage.
Another possible approach would be to start a v2 branch and rebase it from time to time until it's ready to be released. But since I'm the only person that would work on it, I can just keep it locally.
atilaneves
commented
2 weeks ago Removing deprecated code means changing the API - I agree that the version should be bumped to 2.
Release v1.30.0 was a massive release (337 commits).
The main changes were:
Dependencywas made a discriminated union and its various components were broken down;Once v1.39.0 is released, we can merge this PR and get rid of a lot of deprecated code, which will also massively simplify future work.