Description
HNix would not be able to keep backward compatibility on the package split, and we would need a huge API refactor for that anyway.
But after that roughness - we better stop worrying the devs with hard version drops.
There is no without some patina of cruft, in real-world to do a good craft.
In many cases it is easy, and in many cases useful (giving better names) to preserve backward compatibility.
Backward compatibility can be kept in the same module that reexports the Internal one, since the outer module is hollow anyway, it also can be a hideaway storage for backward-compatible stuff.
But with the number of changes, we would accumulate there may be a lot of stuff to backward compatibility.
And I am not a fan of endless backward compatibility either. Also with the big size of the API, it would be broken one way or another from time to time anyway.
I'd would say, if someone is known for 5 years that something mundane needed to be fixed, and not did it - then he probably did not wanted it to stay working in the first place.
I'd established something like:
2 years of a grace policy.
For harder and more in-depth things - 3.
And if a lot people very loudly complain - 5 years.
And keep trow that warning with the date after which it would be removed. 5 birds 1 stone:
- really need change something - you can, because in many cases backward-compatibility is easy to provide. Do it in the major release window (when someone already broke the API) and right when doing it - in the old function add backward-compatibility trow to warning level (at least to terminal, or into a system journal) of the deprecation on the date+2years.
- that just documented in the project when the deprecation is permitted
- people stay happy, because of backward compatibility
- boundaries of support are established and people are informed
- every time they use the backward-compatibility - they are informed particularly what where they need to port to the new version
- because people informed what to migrate and bothered by warning/message - they are more likely to migrate
- because they are informed of needed migration - if migration or deprecation is a problem - they would reach-out - seems much better then just dumping the breakage on them
- if they reach-out you can tackle the problem, and maybe even suggest a proper solution
- if they are right or worried - extend the grace period
- when the period ends - you are free to clear 2-5-year-old cruft from the project
So this simple solution has many benefits and self-manages itself.