search

Bouni / python-luxtronik

python-luxtronik is a library that allow you to interact with a Luxtronik heatpump controller.
MIT License
37 stars 20 forks source link

Auto bump version on release #60

Closed Bouni closed 1 year ago

Bouni commented 1 year ago

I forgot multiple times in the past to bump the version in setup.py

I suggest that we let a GH action bump the version automatically when a new release is published. May be its as easy as putting a placeholder in setup.py and let that be replaced with sed prior to publishing to pypi.

Here's an example on how we could do it:

https://github.com/grst/python-ci-versioneer/blob/master/.github/workflows/python-publish.yml#L20-L30

Bouni commented 1 year ago

@kbabioch Do you know of a way to test GH actions without actually push and release on GH?

kbabioch commented 1 year ago

No, unfortunately not. Seems like this is not officially supported, but there are projects like https://github.com/nektos/act

Bouni commented 1 year ago

I'll see if I can simulate this with act, thanks for the hint 👍🏽

Bouni commented 1 year ago

I did a test with a dummy repo and it seems very easy to do this:

The version in setup.py is set to "dev" https://github.com/Bouni/auto-version-bump/blob/main/setup.py#L9

And on release sed is used to replace that with the version tag:

https://github.com/Bouni/auto-version-bump/blob/main/.github/workflows/publish-to-pypi.yml#L15-L20

Heres the output of the GH action:

https://github.com/Bouni/auto-version-bump/actions/runs/3959719296/jobs/6782909300#step:3:16

I'll submit a PR soon. Any thoughts on the @kbabioch ?

Bouni commented 1 year ago

I just have seen that we need to update that workflow anyway: https://github.com/pypa/gh-action-pypi-publish/tree/release/v1#-master-branch-sunset-

kbabioch commented 1 year ago

I'll submit a PR soon. Any thoughts on the @kbabioch ?

That should work fine, as long as we stick to the versioning scheme and don't use the releases for anything else.

From my point of view this is a good approach for now. If we need to change/adjust the release process later on, we could adjust it.

By the way: There is also https://test.pypi.org/, which is a clone of the Python Package Index (it's already used in the GitHub action). We could delete the last item (Publish to PyPI) and test it first, then re-enabling it later on.

I just have seen that we need to update that workflow anyway: https://github.com/pypa/gh-action-pypi-publish/tree/release/v1#-master-branch-sunset-

Will you take care of this? If I understand this correctly, it is as easy as replacing a string with another one :-).

Bouni commented 1 year ago

@kbabioch I submited a PR just for the version bump and will submit another for the sunset thing.

I would like to switch the versioning to YYYY.MM.NN like HA does it, its way nicer than X.Y.Z in my opinion. What do you thing about that?

kbabioch commented 1 year ago

I would like to switch the versioning to YYYY.MM.NN like HA does it, its way nicer than X.Y.Z in my opinion. What do you thing about that?

I would continue with the X.Y.Z format, as this represents semantic versioning. Personally I think for libraries / APIs this makes more sense than using some kind of date code for the version.

For instance, we could support multiple versions in the future, i.e. something like 1.2 and 2.1. Both of them have different features, but could could need a patch to an issue resulting in 1.2.1 and 2.1.1 without breaking the API for users of the library.

For Home Assistant the date versioning makes more sense, because they don't provide stable APIs over a long period of time. Home Assistant constantly breaks something, because they are living in a very fast / flexible / nasty world.

So, personally, I would stick to the existing versioning and bump the major version every now and then, when there is cool new features and/or major breakage of the API.

On the other hand I don't have too strong feelings about it. I will try to use the latest version of the library anyway :-).