Conversation
| @@ -1,2 +1,2 @@ | |||
| """Backport CPython changes from master to maintenance branches.""" | |||
| __version__ = '1.2.1.dev1' | |||
| __version__ = '1.2.1' | |||
There was a problem hiding this comment.
btw what do you think of having scm-based versioning?
There was a problem hiding this comment.
What do you mean by scm-based versioning?
There was a problem hiding this comment.
Git tag being the source of truth for the version. Currently, it's manual update of version in Python module followed by tagging the commit. But there are flows, where it only sits in Git, so it would need you to just push a git tag to trigger the whole flow without extra steps.
There was a problem hiding this comment.
Ah ok. This version info is needed for flit though.
There was a problem hiding this comment.
Right, so when using setup.py I use setuptools_scm to make dist have info about version. It should be possible with flit as well.
There was a problem hiding this comment.
Hmm, I think I'll keep the current workflow for now.
Interesting idea though, I'll have to think about it. Thanks!
There was a problem hiding this comment.
Ok I'm interested now in deriving the version info automatically somehow, but I'd like to hear more first of what the workflow would look like.
There was a problem hiding this comment.
Well, I need to check what's available for flit, but in general it would be triggered just by pushing a tag and during build something figures out the version and puts it into metadata. setuptools_scm, for example, has a mode, where it'll create the python module from version if the project itself needs to use it (however it's also retrievable via pkg_resources part of setuptools).
In case of setuptools_scm, during development it uses last tag plus commit marker for versioning, but that's configurable.
As for prerequisites, you'll likely need to put a commit with changelog in git and tag afterwards.
Some ppl use tools like towncrier or reno to enforce changelog fragments be submitted along with each PR and then can fail tagged builds if those are not converted into common changelog.
I think I'll try submitting some demo PR with implementation once I have some time.
There was a problem hiding this comment.
Ok thanks. Before you go ahead with some demo PR, let me try to digest all of the above and decide whether it's worth the trouble. (sounds more complicated that I wanted) 😅
I definitely want to further automate this somehow.
There was a problem hiding this comment.
Well, let's separate stages here:
- Removing need to track version in files
- Integrating changelog generator
|
Huh why does this triggers the "blurb" in 3.5 build? |
|
I'm going to ignore the failed build on Python 3.5. |
|
@webknjaz So I just need to tag this brach with release |
|
Correct |
|
Blurb was triggered because it's a PR. Tagged commit will have a separate build in CI, where blurb jobs are going to be hidden. |
|
I've made this tag: https://github.com/python/core-workflow/releases/tag/cherry-picker-v1.2.1 |
|
And it's live in PyPI! 🌮 Thanks @webknjaz !! |
3 participants
No description provided.