Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for a release 5.0.1 #2183

Merged
merged 1 commit into from
May 27, 2024
Merged

Conversation

flaeppe
Copy link
Member

@flaeppe flaeppe commented May 25, 2024

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

@flaeppe flaeppe requested review from intgr and sobolevn May 25, 2024 17:57
Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@flaeppe
Copy link
Member Author

flaeppe commented May 27, 2024

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

Copy link
Member

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@flaeppe flaeppe merged commit d9b47af into typeddjango:master May 27, 2024
36 checks passed
@flaeppe flaeppe deleted the fix/prepare-5.0.1 branch May 27, 2024 11:13
@flaeppe
Copy link
Member Author

flaeppe commented May 27, 2024

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
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

@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
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

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

@intgr
Copy link
Collaborator

intgr commented May 27, 2024

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

@intgr
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

@intgr I've opened #2186

@intgr
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

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
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

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
Copy link
Collaborator

intgr commented May 27, 2024

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
Copy link
Member Author

flaeppe commented May 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants