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

version in about should be auto updated on release #42

Open
3nids opened this issue Feb 11, 2021 · 3 comments
Open

version in about should be auto updated on release #42

3nids opened this issue Feb 11, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@3nids
Copy link
Member

3nids commented Feb 11, 2021

I would suggest to have it modified by a sed command too that'd be easier no?

ping @Guts

@Guts Guts added the enhancement New feature or request label Feb 11, 2021
@Guts
Copy link
Collaborator

Guts commented Feb 11, 2021

Just to track the upstream discussion: #39 (comment)

Personal XP

Let me share how I do release workflow on my side:

  1. I and/or fellows develop on the codebase: commits, PRs, merges/conflicts, CI fails and successes... daily story that we know
  2. At a moment (or defined before in a roadmap/milestone/wet finger in the wind/whatever), it's time to release
  3. Clean up, doc update, etc.
  4. Then, manual steps:
    1. I bump the version in about module (or setup or wherever the version number is stored)
    2. I/we consider this is the last commit to the version with an explicit commit message: "Bump version to 2.0.0".
    3. I/we tag this commit with the version number (without the ugly v prefix <-- personal esthetic opinion)
  5. The CI:
    1. create the changelog,
    2. the GitHub/GitLab release
    3. deploy the package to the relevant platform (npm, pypi...)
    4. deploy the package as release asset
    5. and spreads the world (Slack hooks, etc.)

Why keep it manual? Because it forces me (or another commiter) to perform a final check-list in "full consciousness".

But

I'm also used to automate it: sed or specialized lib as mentioned. So no problem for me 😸.

Steps:

  • read the version from about in different files (setup, cli...)
  • run the sed on this unique file

@Gustry
Copy link
Collaborator

Gustry commented May 11, 2021

This has been changed in e96b77f

Just to keep track :

  • Update changelog if possible. Nothing will fail if the changelog is not done, or it can be done after the tag...
  • Eiter we tag from CLI, the release will be created on GH, with the artifact uploaded
  • Or we create the release from GH, the artifact will be uploaded as well to the existing release

No need to edit any file for the packaging

@Guts
Copy link
Collaborator

Guts commented May 11, 2021

This is exactly this kind of code (in setup.py) I don't like to see or maintain.

Not smart enough to handle different cases and much time eater than a manual change of the version number...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants