Policy about major changes with possible breaking changes #2654
Description
There are a few issues and PRs marked as Breaking changes and a few mentioning the 0.5 milestone. Some of these are 5, even 7 years old.
There might be other changes that are not even considered because they would be breaking changes.
I understand the desire to protect people from breaking changes, but on the other hand this seems to prevent a lot of progress.
v4.0 was releases on Jun 23 2020, that's almost 5 years.
mdbook still supports the legacy book.toml format that, if I am not mistaken, was deprecated in 2017.
(git blame src/config.rs puts the warning message to a commit on 2017-11-12)
I'd like to suggest we adopt a policy of more frequent major version changes with (possibly) breaking changes. People who don't have time to make the changes needed for the upgrade will be able to stay with the previous version of mdbook. We will be able to make progress faster.
For example I'd already remove the support for the legacy configuration format (just opened it #2653).
Then if we encounter another issue with breaking changes we can release it as version 0.6. If possibly after warning about it for some time.
I think my main point is that it would be better to have a few releases with breaking changes than to wait to collect many breaking changes and release them at once.