search

inyokaproject / inyoka

All-in-one portal software
http://inyokaproject.org
Other
13 stars 3 forks source link

Version schema #1313

Open chris34 opened 4 months ago

chris34 commented 4 months ago

At the moment Inyoka still uses zero-based versioning. It's questionable whether this fits the project. Some ideas include:

encbladexp commented 4 months ago

I personally would prefer Django Major, Minor and the Patch level whenever we do something on our side.

encbladexp commented 3 weeks ago

Some addition: We could also integrate e.g. setuptools.scm, so get the version out of git or something like (would that be helpful, after all?).

chrysle commented 3 weeks ago

(would that be helpful, after all?).

Spares some effort that is required to manually update the version number in the source code. I'd be in favor.

chris34 commented 3 weeks ago

just to be clear: do i see it right that setuptools.scm will only extract the version from a git tag? So the git tag i have to do on my own?

At the moment we still have bump2version (see release procedure) So i dont have to do the math in my brain :brain:.

https://github.com/c4urself/bump2version is no longer maintained and recommends https://github.com/callowayproject/bump-my-version

bump-my-version looks quite sophisticated. (At least for semver and calver…)

encbladexp commented 3 weeks ago

Exactly, you just tag in git, and setuptools.scm will get the version information out of git. If you build a wheel package with it, its tagged with the version, and you could use the standard packaging stuff to retrieve the previously tagged version. 🪄

chris34 commented 3 weeks ago

so if i download a tarball version for a release from github, i will not know from a file which version I'm currently looking at? Dont know if i like that. I'm still more on the bump-my-version side (where the version is automatically incremented according to a scheme, updated in a file and also a git commit with a tag is created).

And to come back to the topic: I would even consider calver. The only drawback i see is that a way out is quite hard. (only with a jump from a 202x to 3000 version)

Feel free to give counter arguments.

chrysle commented 3 weeks ago

so if i download a tarball version for a release from github, i will not know from a file which version I'm currently looking at?

It's possible to configure setuptools_scm to create a file containing the version.. The jsondiff package is an example for this functionality. However, this functionality would only be useful if Inyoka was to be published to PyPI and users downloaded the sdist directly from there.