-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add command to check for vX.Y.Z tag vs pybind11/_version.py consistency. #4757
Conversation
…cy. Piggy-backing hints for converting changelog to release message.
Hi @henryiii did you get a chance to look at this tiny update? I just double-checked the
I think that's exactly what we need as a last line of defense, right before the |
docs/release.rst
Outdated
@@ -47,6 +47,9 @@ If you don't have nox, you should either use ``pipx run nox`` instead, or use | |||
- Update tags (optional; if you skip this, the GitHub release makes a | |||
non-annotated tag for you) | |||
- ``git tag -a vX.Y.Z -m 'vX.Y.Z release'``. | |||
- To ensure the new tag is consistent with the version number in the sources, run this command: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is the current tag number shown? __version__
and pybind11/_version.py
are already forced to be in sync by nox -s tests_packaging
above, if that's all this is doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The nox command only ensures that common.h and pybind11/_version.py are fully self-consistent.
Which is something I take for granted.
The git-diff-grep command would have shown a diff because it would have pulled v2.11.0
from pybind11/_version.py, but at that step in the instructions my working copy had the v2.11.1 changes, just not the version number update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm failing to understand why this would catch anything that git status
or a plain git diff
would not show (or, in my terminal, the current git condition is shown as a colored bar). It's not using or comparing the tag itself at all.
Could it be replaced with "make sure all changes are committed"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simply forgot to update the version number, and everybody else overlooked it, too.
git status
would not have shown anything.
git diff
also would not have shown anything.
git diff v2.11.0
would have shown that the code I had was not what was tagged as v2.11.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooh, oooookay. That seems like an interesting way to so it. Can't you just print out the current version and make sure it's the same as the tag? grep ^__version__ pybind11/_version.py | cut -d'"' -f2 | sed 's/^/v/'"
should show the current tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And grep ^__version__ pybind11/_version.py
would be enough for a human user to verify the code states the version they just tagged.
docs/release.rst
Outdated
- ``git diff "$(grep ^__version__ pybind11/_version.py | cut -d'"' -f2 | sed 's/^/v/')"`` | ||
- There should be no diff. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- ``git diff "$(grep ^__version__ pybind11/_version.py | cut -d'"' -f2 | sed 's/^/v/')"`` | |
- There should be no diff. | |
- ``grep ^__version__ pybind11/_version.py`` | |
- This should print the version you just tagged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed a slightly different wording before seeing this comment.
Give me a moment to try again.
Simpler is better I agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plus it's not great for the "working" path to produce no feedback that it worked. Your wording is fine.
@henryiii I removed a few line breaks to make it look better in the web view. https://github.com/pybind/pybind11/blob/2b54c6539951cbd819b00b2140182bcf9a100ed7/docs/release.rst Do you know if we can have the line breaks in the .rst file without making it look weird in the web view? It's still not perfect, but good enough? |
Lesson learned: This is NOT GOOD: ``` - Bullet nesting level 1. - Bullet nesting level 2. ``` This is BETTER: ``` - Bullet nesting level 1. - Bullet nesting level 2. ``` Also consistently adding empty lines between bullet points, to make the .rst file easier to read. Also piggy-backing a few very minor enhancements.
With a lot of trial and error I finally figured out then main problem: This is NOT GOOD:
This is BETTER:
With that and some minor miscellaneous polishing the rendered page on the web looks nice now. I'll go ahead and merge. |
Description
Slightly expand instructions based on lesson just learned (see #4756).
Piggy-backing hints for converting changelog to release message.
Suggested changelog entry: