src/VERSION

[StoneyJackson]

I'm struggling to get the VERSION file to be updated on release. I going to remove it again and work on it in a separate repository. For now, the version will only be determined by a git tag. That means the version of PLCC outside of a git repository will be "unknown".

While I work on this, we might consider assuming that all deployments of PLCC are in the context of git. It certainly makes updating PLCC to newer versions or rolling it back to an older version. This assumption would also simplify the release mechanism and commit history. If we have to modify the VERSION file during release, an extra commit must be made.

[jashelio]

I think I know what this means, but a slightly longer explanation of the mechanism and its pros and cons might be worth mentioning at our next meeting. Here are the assumptions I'm making at the moment. (1) If we could assume that all deployments of PLCC are from git, then the version number issue would be solved. (2) The copy in pithon.net would have to be an export from the git repository. You can correct and augment my conclusions at our next meeting.

[StoneyJackson]

@jashelio You got it.

Your notion of exporting code from the repository is also correct. Usually you want to mark a copy of the code with its version number when it leaves the confines of the repository. Now zip files are created for each release (https://github.com/ourPLCC/plcc/releases). I wonder if I can convince the release tool to generate a VERSION file and include it in the zip. That would solve part of the problem.

There would still be the problem of someone cloning the project, and then deleting the repository but keeping the code (e.g., delete .git/). Now you'd have code missing a version.

I really like the idea of using git as our distribution mechanism. Upgrading to the latest is simply git switch main ; git pull. Rolling back to a particular version is git checkout v5.0.1.

Alternatively, we could try to get into package managers. I've never gone down this road. Who knows maybe it's easy. Minimally we'd want to target Homebrew and Debian's apt-get. It might be nice to also get into Alpine's (apk) for the sake of small Docker containers. But this illustrates why I haven't gone down this path. There are many different package managers to support, which will likely increase maintenance costs (time) than would having a the singular distribution mechanism, git. Supporting zips is technically a second distribution mechanism.

[StoneyJackson]

This is relevant to this issue: https://packaging.python.org/en/latest/guides/single-sourcing-package-version/