Release 21.2.0

[rodrigc]

Trac link: https://twistedmatrix.com/trac/ticket/10091

[rodrigc]

I'm trying to follow the steps same as what @hawkowl did here: #1228

[glyph]

I guess I need to make the same comment again :)

#1228 (review)

We shouldn't be running the lint step to check for news fragments on the release branch, since there really shouldn't be any.

[rodrigc]

@glyph In this section: https://github.com/twisted/twisted/blob/release-21.2.0-10091/docs/core/development/policy/release-process.rst#post-release

The release document mentions to reset the version to $RELEASE.dev

In https://www.python.org/dev/peps/pep-0440/ , the example they give is:

0.9
1.0.dev1
1.0.dev2
1.0.dev3
1.0.dev4
1.0c1
1.0c2
1.0
1.0.post1
1.1.dev1
...

So I would like to change the release process doc to in the post-release steps to bump the version to `post`.

I will then do that in this branch before merging it back to trunk.
Is that OK?

[rodrigc]

@glyph also, if I run this command:

python -m incremental.update Twisted --post

It bumps the version to post0:

Updating codebase to 21.2.0.post0
Updating /Users/crodrigues/twisted13/src/twisted/_version.py

Is post0 a valid pep440 version? If I read: https://www.python.org/dev/peps/pep-0440/#post-releases

The post-release segment consists of the string .post, followed by a non-negative integer value.

For dev releases: https://www.python.org/dev/peps/pep-0440/#developmental-releases

it also states:

The developmental release segment consists of the string .dev, followed by a non-negative integer value.

But the example the give, while it shows dev0 as valid, it doesn't list post0, and just lists post1.

Is incremental doing the right thing with the --post flag, or is that a bug?

I'm not sure.

[ambv]

I'm no authority on versioning, Black being a great example why nobody should be listening to me in this matter. However, since @rodrigc asked me for feedback: in my opinion post0 is perfectly fine just as CPython itself uses a0 before the first alpha is tagged. The language of PEP 440 uses the unnatural but extremely precise term "non-negative integer value". It would be easier for Nick and Donald to say "positive number" if they didn't precisely mean to include 0 in there.

This looks like one of those cases where having listed examples raises new questions beyond the actual text. PEP 8 in particular is great at this 😬

[rodrigc]

@ambv thanks for your feedback. I just needed an extra pair of eyes/opinion. :)

I will make a slight change in the Twisted release docs for the post-release steps to use a post0 version.

[rodrigc]

Oh sheesh, looks like there is a bug in incremental:

    File "/tmp/pip-req-build-zvf8johl/src/twisted/__init__.py", line 11, in <module>
      from twisted._version import __version__ as version
    File "/tmp/pip-req-build-zvf8johl/src/twisted/_version.py", line 10, in <module>
      __version__ = Version("Twisted", 21, 2, 0, post=0)
  TypeError: __init__() got an unexpected keyword argument 'post'

[cjwatson]

I added postrelease support to incremental in twisted/incremental#37, but there's been no release of incremental since then.

[rodrigc]

@cjwatson Just to confirm. https://pypi.org/project/incremental/ shows that 17.5.0 was the last released version of
incremental. That is from here: https://github.com/twisted/incremental/tree/incremental-17.5.0 which is from May 2017.

Your patch twisted/incremental#37 was merged into incremental in September 2019.

So we need to do a new release of incremental to get your fix.

Does that sound right?

[cjwatson]

@rodrigc That's my understanding, though I have no idea what else might be involved.

[rodrigc]

@cjwatson I confirmed your --post fix is definitely in the incremental master branch and it does work.

Do you know how I can update the Pypi release at https://pypi.org/project/incremental/ ?
I'm not an expert at Pypi stuff.

[cjwatson]

@hawkowl is the only person with maintainer permissions there at present, so she'll need to either give you permissions or do the release herself.

Generally speaking, one releases to PyPI roughly as follows:

• Do whatever project-specific preparation is needed (I guess something towncrier-ish and making an appropriate git tag? Release 17.5 incremental#34 seems to have been the last time round);
• Build an sdist and/or a wheel (it looks as though incremental currently has both formats on PyPI, so it would seem polite to do the same);
• Use a tool such as twine to upload those.

I really can't speak to whether there are any project-specific procedures around incremental that would need to be followed here, though.

[rodrigc]

@cjwatson Hmm, @hawkowl hasn't been in contact for some months, so it may take some time to get access to this Pypi repo.

As a short term workaround, do you think I could put an entry in https://github.com/twisted/twisted/blob/trunk/setup.cfg#L31
to change that to get incremental from Git SHA twisted/incremental@0f8be2a ?

Do you know the syntax for that offhand?

[cjwatson]

@rodrigc Sorry, I have to bow out of the conversation at this point as I don't know the answers to your questions.

[rodrigc]

@cjwatson I was just given access to the Pypi repository for Twisted incremental. I just did a 21.3.0 release which has your patches for PEP 440 compliant post release support.

I'm going to use that version in this PR.

Thanks for your submission, and sorry it took so long to get it released!

[glyph]

@rodrigc — So I think the intent of PEP 440 is that "post" releases are those made to fix artifact or docs issues and generally don't change the code, making them a poor choice semantically for what we want here. The idea is that when you release X.Y.Z, you switch your source tree to be versioned as <next version>.dev0, but this assumes that you know what "next version" is, which doesn't fit well into CalVer. If you know you're developing X+1.0.0 or X.Y+1.0 you can have your release process bump you to whatever with a .dev0 process, but in CalVer, you just know that you are done with X.Y.Z.

However, with @ambv's blessing - and I want to be clear, this conclusion is 100% his fault - I think we should flout this convention and go with X.Y.Z.post0 anyway, because it sorts the way we want (it's greater than and will supplant X.Y.Z), given the information we have at the time we want to bump the version. Perhaps at some point we should lobby for some PEP440 errata allows for .postdev0 or somesuch.

Hey @hynek just flagging this for you too in case it's relevant to your new career as a full-time SemVer thought leader

[glyph]

@rodrigc

So I would like to change the release process doc to in the post-release steps to bump the version to post.

I will then do that in this branch before merging it back to trunk.
Is that OK?

To rephrase my comment above:

"yes"

[glyph]

Untagging myself because anyone should be able to review this and I've had a lot of questions personally directed at me this week so hopefully something that someone else can do, someone else will do :)