Thanks to visit codestin.com
Credit goes to github.com

Skip to content

cherry-picker 1.2.1 release #282

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

Merged
merged 2 commits into from
Aug 21, 2018
Merged

cherry-picker 1.2.1 release #282

merged 2 commits into from
Aug 21, 2018

Conversation

Mariatta
Copy link
Member

No description provided.

@@ -1,2 +1,2 @@
"""Backport CPython changes from master to maintenance branches."""
__version__ = '1.2.1.dev1'
__version__ = '1.2.1'
Copy link
Contributor

Choose a reason for hiding this comment

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

btw what do you think of having scm-based versioning?

Copy link
Member Author

Choose a reason for hiding this comment

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

What do you mean by scm-based versioning?

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah ok. This version info is needed for flit though.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I think I'll keep the current workflow for now.
Interesting idea though, I'll have to think about it. Thanks!

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, let's separate stages here:

  1. Removing need to track version in files
  2. Integrating changelog generator

@Mariatta
Copy link
Member Author

Huh why does this triggers the "blurb" in 3.5 build?

@Mariatta
Copy link
Member Author

I'm going to ignore the failed build on Python 3.5.

@Mariatta
Copy link
Member Author

@webknjaz So I just need to tag this brach with release cherry-picker-v1.2.1, and travis will take care of publishing to PyPI, correct?

@webknjaz
Copy link
Contributor

Correct

@webknjaz
Copy link
Contributor

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.

@Mariatta
Copy link
Member Author

I've made this tag: https://github.com/python/core-workflow/releases/tag/cherry-picker-v1.2.1

@Mariatta
Copy link
Member Author

Building now: https://travis-ci.org/python/core-workflow/builds/418801217

@Mariatta
Copy link
Member Author

And it's live in PyPI! ๐ŸŒฎ Thanks @webknjaz !!

@Mariatta Mariatta closed this Aug 21, 2018
@Mariatta Mariatta reopened this Aug 21, 2018
@Mariatta Mariatta merged commit 3ee9e89 into master Aug 21, 2018
@Mariatta Mariatta deleted the Mariatta-patch-1 branch August 21, 2018 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants