Intentions for Milestone 3.0? Release philosphy?

[rsyring]

I see #166 has been assigned Milestone 3.0. That milestone currently has 3 closed issues but 10 open issues assigned. There are no issues assigned to the 2.4 milestone.

I'd like to be able to do the work on #166 and get it released relatively quickly. Any objections to continuing to make minor version releases in the 2.x series while we "build up" to 3.0?

Also, on that note, what is the "big picture" for milestone 3.0? Why the major version bump? Are there incompatible changes already committed and/or being contemplated?

I personally am a proponent of frequent releases assuming you aren't intentionally introducing incompatibilities, docs are updated, and all tests are passing. If bugs are introduced accidentally, they can be fixed relatively quickly and a new release made. I also believe in having scripts/tools for automating the release to make releases relatively painless. Any objections to adopting this philosophy for releases going forward?

[davidism]

At this point, 3.0 is somewhat of an indicator of "hey, it's been a pretty long time." If I remember from when I started organizing last time, I mostly wanted to signifiy the change in how we configured things, mainly #438 and all the other issues about pool, engine, and session arguments. But there's also potential for bigger shifts, such as pagination (#282), or removing deprecated or old features. And I'd really like to bump our minimum SQLAlchemy version to at least 1.0 or 1.1.

As long as it remains compatible and doesn't add work for us later, #166 is fine to have in 2.x. 3.x means we can be somewhat more liberal in how we handle API changes, which especially after so much time since a release could be helpful. With a lot of the projects, a major time sink for me was verifying that the changelog listed everything and that is was backwards compatible, and I didn't always catch everything. I would like to stop working on 2 and move to 3 eventually, but if there's something you think should be in 2 sooner, that's fine.

I don't mind faster releases, especially if we have good processes in place regarding tests, docs, and the changelog. And I don't mind fast turnaround on bugfix releases either. Just let me know when you think we're ready for a release, I'll give it a final review and upload it..

[davidism]

Also, can you join our Discord so we can ping/discuss there too: https://discord.gg/t6rrQZH

[rsyring]

I understand your desire to do the 3.x release, especially because it frees us a bit more with respect to incompatible changes. But it's actually for that reason that I'd like to delay.

People have been waiting a bit for a release and to see the project pick up on activity. If we give them a 3.x with incompatibilities, then it's harder to upgrade.

If we do 2.x releases, then they can upgrade mostly without worry, get some of the features they have been waiting for, without much risk of breakage. That feels like a win to me as a developer as I contemplate the updates to 10+ projects once we make a release.

Then, down the road when we actually do a 3.x release with incompatibilities, there is a sense of confidence by our user base that it's worth it (ideally).

I would like to stop working on 2 and move to 3 eventually, but if there's something you think should be in 2 sooner, that's fine....I don't mind faster releases, especially if we have good processes in place regarding tests, docs, and the changelog. And I don't mind fast turnaround on bugfix releases either. Just let me know when you think we're ready for a release, I'll give it a final review and upload it.

Great, thanks for your flexibility.

With a lot of the projects, a major time sink for me was verifying that the changelog listed everything and that is was backwards compatible, and I didn't always catch everything

My preference would be to treat master as the 2.x branch for safe changes and have a 3.0 branch for incompatible changes. That way, the BC decision is made at PR review time and you don't have to go back and "remember".

I also think we can automate creation of the changelog. I'll create a separate issue for discussion of that.

Also, can you join our Discord so we can ping/discuss there too: https://discord.gg/t6rrQZH

Sure.

[davidism]

But it's actually for that reason that I'd like to delay.

Yeah, sorry if that wasn't clear, a 2.4 release is a good idea right now. I just want to be thinking about moving towards 3 as we change and deprecate things.

That way, the BC decision is made at PR review time and you don't have to go back and "remember".

Now I require a changelog entry, even if I write it and force push to the PR, before merging. But I don't know what the current state is, so it still has to be fixed for the past.

I also think we can automate creation of the changelog. I'll create a separate issue for discussion of that.

Automating changelogs is something I have on my radar, and I've been experimenting and discussing with other maintainers, but it's something I need to make a decision on globally for Pallets. We'll get there eventually.

[rsyring]

I've created a 2.x-maintenance branch from the existing 2.3-maintenance branch. It's my intention to continue to work off that branch for all 2.x releases and just tag our versions instead of having a dedicated branch. Given the relatively small amount of developers in this project, I think that will be sufficient for our needs and keep us from having to create a new branch for each minor version release. If that ends up creating a problem, I'm happy to revisit this decision.

I'll also delete the 2.3 maintenance branch. I can re-create it if that's objectionable for any reason.

[rsyring]

I've created milestones with descriptions:

https://github.com/pallets/flask-sqlalchemy/milestones?with_issues=no

It's my intention to get every single issue and PR categorized into one of those milestones so that it's easier to know what to work on. I think the priority would be:

• 2.4
• 2.x
• 3.0

Questions/comments/concerns about that plan welcome.

[rsyring]

It's my intention to get every single issue and PR categorized into one of those milestones

That has been completed.

[rsyring]

An update: 2.4 milestones is almost ready. Waiting for review/approval of #684 and then will work towards a changelog update and release.

[rsyring]

Preparation of 2.4 release is underway in #715.

I also went through and assigned all new issues/PRs to a milestone.

[davidism]

2.4 is out and focus is now on 3.0 in master.