0.3.7 build breaks on rust 1.64, there is no 0.3 branch in this repo

[steffahn]

There are still a few crates out there depending on mdbook 0.3. I believe it would make sense to publish a 0.3.8 version that fixes the same build failure (#1860) that #1861 fixed for master.

I have a branch, https://github.com/steffahn/mdBook/tree/fix_0.3.x_builds that cherry-picks the fix, but there’s no 0.3 branch to open a PR against.

If someone could create a 0.3 branch based on the v0.3.7 tag (8e673c9), then I can open a PR.

If you want to reproduce the build failure, note that building 0.3.7 directly (git checkout v0.3.7; cargo +beta check) does not fail due to an older handlebars dependency in Cargo.lock. Try git checkout v0.3.7; cargo update; cargo +beta check instead.

[ehuss]

I would prefer to not make a release of the 0.3 line which is over two years old. If there are any active projects still using 0.3, they should consider updating to 0.4 instead.

[steffahn]

It’s really a straightforward fix, the cherry-pick applies cleanly, it only swaps two lines of code.

From the perspective of a project maintainer of an “active project” using mdbook 0.3, I agree that the alternative option to upgrade to 0.4 is sufficient. I’m considering users of such crates though, or users of no-longer-really-all-that-active projects, which will simply experience a compilation error that gives no indication as to who’s “at fault”.

Any user of such a project will, following the cargo install foobar way of getting the software, simply get a meaningless error message about `local_ctx` does not live long enough and could not compile `mdbook` due to 2 previous errors. The more knowledgeable user will know about Rust’s stability guarantees and likely first blame rustc, and only later either mdbook and/or the crate they’re trying to build.

I can understand that maintaining 0.3.x versions of mdbook is not a goal, but this fix is so small that it’s almost no maintenance at all. With this in mind, I am curious as to what kind of reasons for deciding not to release a 0.3.8 patch there actually are. Only thing I can come up with is that releasing 0.3.8 now could create the false impression that the 0.3.x versions are actually still “maintained”, but feel free to tell me more about your motivation.

FYI, I’m only opening this issue because I’m trying to address all (legitimate) regressions that this crater run found (by opening issues or PRs), and some crate that depends on mdbook 0.3.7 happened to be part of that. The motivation being to improve user experience with the rust compiler that promised to never do breaking changes, but unfortunately had to break stuff in this case for a fix of a soundness issue caused by an oversight in the implementation details of BTreeMap.

---

Regarding the usage of crates depending on mdbook 0.3, looking at this list where you can see 3 crates with currently >100 monthly downloads, however… mdbook-epub’s downloads are mostly in their -beta versions using mdbook 0.4, and rmemo’s downloads seem to come largely from some automated tests-ish operations that download every version (judging by its downloads graph), leaving only mdbook-latex which has a surprisingly high (but somehow fairly natural-looking) number of downloads for what it is. Though, of course, >100 monthly downloads also is a significantly high limit; how often do you re-install old crates? So all-in-all, I do assume there will be quite a handful of users affected by the breakage if it’s not addressed.

[Dylan-DPC]

I wouldn't suggest a new release :

• if we do release a new 0.3.8 people would assume that "0.3" is being actively maintained and would expect us to backport other compatible fixes which we do not plan on doing.

• 0.4 was released about 2 years ago, which is a good enough time for most dependents to update to the latest version. We cant really help with outdated/abandoned crates. I will look into the list of crates using older versions and see if any of those can be updated to the latest one without much breakage.

• afaik crater locks the dependencies so it could be that some of those in the results are outdated and have been updated at a later version from what crater has.

[ehuss]

I understand it is a small, straightforward fix. I also understand you are trying to soften the blow of a breaking change. My reasoning is as @Dylan-DPC says. There may also be issues around CI and the deploy scripts. Also, 0.3.7 currently triggers the unaligned_references warning (with the lock), which will also break in the future.

If mdbook was in a stable release cycle (such as 1.0), then that may be a different story. However, it is intentionally not at this time.

[ehuss]

I'm going to close as I don't think we will make new releases to old versions. I'm sorry that is probably not the answer you wanted to hear.

[steffahn]

No worries. I personally don’t really care too much either way. I just wanted to make sure to allow crate maintainers to avoid potential breakage; ultimately, deciding on what level of support or non-support old crate versions receive is not up to me :-)