| ▲ | rtpg 3 days ago | |
I feel like people who crave stability pull all the wrong lessons from how to get to stability when doing this sort of "ok we'll make _one_ major version with all the breaking changes we've built up over time". This feels like a repeat of the Python 3.0 strategy, though obviously at a much smaller scale. Some stuff is of course hard to roll out but to me it feels "obvious" that having a 4.0 with the inheritence change (or even better, a 2.1 with a toggle on that change!), then a 5.0 with some other changes, then a 6.0 with other changes... all feels way easier to manage than a 4.0 with all the changes at once. We have version pinning! People who want 2.0 can have 2.0 "forever", so version numbers that go up very high are not actually a problem. Many releases can of course be a bit of a frustration from a release maker's perspective, but given that htmx is the way it is (ain't even getting type checking helping you out on any of this like you would with React!), having the gradual path seems way better. "I think I've handled the 10 changes in between 2.0 and 4.0... but forgot the 11th change" is a constant annoyance with these huge major version bumps. I will once again point to the Django strategy of having breaking changes be rolled out over several releases, including in between releases where "both" models exist. It is a very nice way to do release management when rolling things out, gives good checkpoints for pushing things out, and overall means users are seeing less bugs. Going from `XMLHttpRequest` to `fetch` really might not be a feasable thing to toggle, but a lot of the other stuff in that list feels like it. | ||
| ▲ | imtringued 3 days ago | parent [-] | |
>I feel like people who crave stability pull all the wrong lessons from how to get to stability when doing this sort of "ok we'll make _one_ major version with all the breaking changes we've built up over time". Yeah this is a huge fallacy. If you do a breaking change, you want to do as few breaking changes at once as possible, with as little impact as possible and in the best case scenario you're in contact with every single person that is affected by the breaking change, so that it can be handled without anyone noticing anything other than having to bump a library version, which they were doing anyway since they're running a new Python version in the first place. The dumbest change in python 3 was removing the print statement [0]. Maximum breakage, minimum gain. They could have introduced the new function as println() and deprecated the print statement in Python 3. | ||