What are your plans regarding 1.0 and further major releases?

[Expurple]

I've noticed that the changelog for 0.12.10 (a patch release) contains some new features. This is understandable, given that 0.13.0 would indicate potential breaking changes and prevent automatic updates. But wouldn't it be nicer to use 1.x bumps for indicating non-breaking features?

I know, here you've already outlined your plans for the new 6 month 0.x cadence in the near future. But I disagree with this statement:

As our major dependency SQLx is not 1.0 yet, technically we cannot be 1.0.

No, you can. You just need to make breaking releases when your public dependencies do. It can be 1.0, 2.0, 3.0 just as well as 0.12, 0.13, 0.14. The upside is that the version numbers can become more meaningful by using all three components. What are the downsides for you? Do you want to mark 1.0 with the addition of some major missing feature? Is that on a roadmap somewhere? Or do you want to establish longer lifecycles for major releases starting right with 1.0? Something in the range of multiple years? Note that in 2021, 2022 and 2023 SQLx had only one breaking release per year, so you should already be able to have a 1 year cadence. Or do you consider this simultaneously too long for the current development pace and too short for a "proper" stable release? Personally, I wouldn't consider that any more "unstable" than the current state of things.

And as always :)

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

Thank you.

[tyt2y3]

Hi, thank you for raising these concerns. I very much would want to release a 1.0 version! But SeaORM as an ORM has a vast API surface, and I have been trying to refactor bit by bit to make it possible to add new features without breaking. But Rust's API contract is so strict that, I worried, once we are committed to a 1.0, we'd fall into the dilemma of 1) not breaking the API, thus blocking new features 2) release a new major version anyway, and fragment downstream.

So you are right in that 0.12 is a prolonged experiment to see whether I can shove in new features, and it's been fine so far. There are still a few breaking changes I have in mind, might as well just list them here:

1. Add const ARITY: usize to PrimayKeyTrait so that we can use const generic
2. Bound ActiveModelBehaviour to EntityTrait so that we can implement after_select, etc
3. Re-think all SQLite type affinity

If all goes well, we can probably make the next release a 1.0.0-rc

[Expurple]

2. release a new major version anyway, and fragment downstream.

Note that this is already the status quo in the 0.x series, and maybe it's not as bad as it seems. At least, SeaORM is not a low-level "building block" that's likely to appear multiple times in the dependency graph and cause dependency hell

[tyt2y3]

Update: we will make the next major release a release candidate for 1.0