Prepare for a release 5.0.1

[flaeppe]

There's already a bunch of contributions since 5.0.0, I was thinking it might be time to release a 5.0.1.

I've updated some numbers in preparation here, let me know if you know anything more that we should prepare before creating a new release.

Related issues

• Ref: Simplify matrix-test, drop old django versions #2133 (comment)

[sobolevn]

I would like to include these two PRs:

• Migrate 'test_conf.yml' to 'assert_type' tests #2182
• Formset get_queryset() returns QuerySet #2174

[flaeppe]

@sobolevn the 2 PR:s you mentioned have been merged. What do you think, should we proceed with doing a release?

[sobolevn]

🚀

[flaeppe]

Haha @sobolevn the django-stubs release worked this time (yay!) but it seems that django-stubs-ext publisher didn't work.

Action run: https://github.com/typeddjango/django-stubs/actions/runs/9253970455/job/25454746769

Fortunately we can just retry it if we update the publisher.

Does the publisher you set here: #2150 (review) look like below?

Owner: typeddjango
Repository name: django-stubs
Workflow name: release.yml
Environment name: release-ext

[intgr]

Sorry, I didn't have time to review, I was away all weekend and had a busy Monday. But everything looks great to me 👍

I can also release django-stubs-ext manually, @flaeppe should I do it?

[flaeppe]

@intgr no problem and yes, go ahead and do a manual one. I saw that there was some ext/ changes that we want released. Would be great if you could push that out, thank you!

[intgr]

Actually, you missed one thing. The django-stubs-ext>=5.0.0 requirement should be updated every time. We don't want to support arbitrary combinations of django-stubs and django-stubs-ext. #2104 is a sensitive change in this regard.

Let's make a quick 5.0.2 release which bumps the dependency?

[flaeppe]

Sounds good! But I'm wondering, can that requirement be updated before we've done a release of django-stubs-ext?

[intgr]

Yes, the django-stubs upload to PyPI will pass even if django-stubs-ext isn't released yet.

[intgr]

But it's a good point, we should tweak the release.yml workflow, such that django-stubs-ext release is done first. Otherwise users may get surprising dependency errors between the releases.

[intgr]

Actually, you missed one thing. The django-stubs-ext>=5.0.0 requirement should be updated every time.

And it's not at all your fault. We should have a checklist of what needs to be done for each release, written down somewhere.

[flaeppe]

I'm not sure if it's a good idea to create a dependency in the release workflow? A problem that then shows up is that if e.g. django-stubs-ext succeeds but django-stubs fails, it's not possible to rerun the release action.

I suppose it then becomes a measurement of which problem is worse, since I don't think we can support both, at least not in a simple way.

And it's not at all your fault. We should have a checklist of what needs to be done for each release, written down somewhere.

I agree that we should try to write it down, but I should've figured it out. I was looking through the PR:s marked with a "release notes reminder".

I think we should continue with an open issue for the next release (e.g. like #2020). I liked that approach, and then we can try to update that with a checklist and other stuff relevant for the next release.

[flaeppe]

@intgr I've opened #2186

[intgr]

I'm not sure if it's a good idea to create a dependency in the release workflow? A problem that then shows up is that if e.g. django-stubs-ext succeeds but django-stubs fails, it's not possible to rerun the release action.

I suppose it then becomes a measurement of which problem is worse, since I don't think we can support both, at least not in a simple way.

I think we can control this with the workflow concurrency key?

concurrency:
  group: release

Then both release jobs will be run in the same concurrency group and are ran in sequence. And we need to re-order them such that django-stubs-ext starts first.

[flaeppe]

I don't think we should add any concurrency key, because; if a different workflow run with the same key is started, any already running is shut down. That means we could possibly be halfway through releasing and if a new one is started, GitHub actions would cancel the first one halfway through.

I think we rather want to declare needs for django-stubs:

jobs:
  build-and-publish:
    runs-on: ubuntu-latest
    environment:
      name: release
      url: https://pypi.org/p/django-stubs
+   needs: [build-and-publish-ext]
    permissions:
      id-token: write
    steps:
      - name: Setup python to build package
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - name: Install build
        run: python -m pip install build
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Build package
        run: python -m build
      - name: Publish to PyPI
        uses: pypa/[email protected]

That should force sequential runs while allowing us to retry the build-and-publish job only if e.g. it fails

[intgr]

if a different workflow run with the same key is started, any already running is shut down.

That's only if using the cancel-in-progress: true key, which defaults to false AFAICT.

I think we rather want to declare needs for django-stubs:

Sure, that sounds better.

[flaeppe]

That's only if using the cancel-in-progress: true key, which defaults to false AFAICT.

Ah, I missed that section in the docs 🙂 I was also completely oblivious to the meaning of the cancel-in-progress name.

We should do both the above mentioned things then! That would mean any new workflow will wait for a currently running one and we will release django-stubs-ext before django-stubs.

Last addition is that we'll also need to resolve #2187 when we've put django-release-ext as a blocking job, to get everything working.

[intgr]

We should do both the above mentioned things then! That would mean any new workflow will wait for a currently running one

I think that's not necessary, we don't make releases so often that the workflows can run in parallel. 😄

[flaeppe]

I think that's not necessary, we don't make releases so often that the workflows can run in parallel. 😄

That's true! But it's very easy for 2 persons to press e.g. "Rerun failing jobs" for a failed release workflow.