Miss Dada  🏳️‍⚧️

So Diesel 2.0 is a thing that is happening this year, and I'm debating whether I should write a blog post about it. None of the planned changes are likely to affect most users (and we have the same "easy migration" standards we have for deprecations. 1/

1.4 -> 2.0 won't be any harder than any minor release if you had `#[deny(deprecated)]`, but for various reasons there are a few changes we want to make that can't go through a deprecation cycle 2/

But none of these breaking changes are expected to affect most users, which is sorta the point. If they were huge changes, we wouldn't be making them. 3/

So I'm a bit torn here, since I think there's value in saying early and often that this release won't involve major breakage, just stuff that can't be deprecated. On the other hand the post is like "here's some stuff that we made less broken. You won't notice" 4/

But I worry that pointing out some of the stuff we're fixing just makes us look bad since it's mostly "oh we shouldn't have let folks couple to this, we need something more abstract than what we have". And we don't expect most users to be affected...

At the same time I'm worried about the optics of having a 2.0 at all. It's been just over a year since 1.0 (probably 18 months when 2.0 ships). I want to make sure folks can see this is because of our commitment to semver, not because we plan on breaking stuff annually.

It's also unfortunate that we're going to force a lot of libraries to do a new release with `diesel = ">= 1.0, < 3.0"` but that's unavoidable since these changes might actually break libraries

I guess at the end of the day this is what some of the anti-semver folks complain about. I don't expect this to affect 99% of our users. But I do expect it to break *some* folks (especially libraries), so I think it's important to communicate that in our versioning