Rename repo to faim-ipa
tibuch opened this issue · 11 comments
The name faim-hcs is not representative anymore. We should rename the repo to faim-ipa (image processing and analysis).
@imagejan I just realized that we will end up with interesting version numbers for faim-ipa. In essence we will start with version 0.3.0.
I was wondering if we should replace the versioning scheme from major.minor.micro to something date based e.g. YYYY.MM.DD.
Do you have a strong opinion on how we version this package?
Some more information on date-based versioning can be found here: https://calver.org/
I am still in favor of semantic versioning, as it (potentially) provides information about compatible (patch) versions, added API (minor) and breaking changes (major).
I wouldn't mind starting at version 0.27382.0 as long as were still in pre-1.x 😄
NB: of course, it's possible we stay at 0.x forever because the library will never be "stable", but I still like distinguishing between minor and patch version steps to bring across that compatibility information.
I understand. But renaming to faim-ipa is pretty much breaking everything i.e. a major increase would be in order. Which means we start with v1.0.0 😅
Maybe we can do some mix 2024.04_patch? Or prefix it with ipa-0.1.0?
Well, we are starting with a new package name, so it's all fine to just reset it to 0.1.0.
I would argue however that we should keep it increasing to avoid confusions between faim-hcs-0.2.5 and any future faim-ipa-0.2.5 that might exist if we don't do that.
breaking everything i.e. a major increase would be in order. Which means we start with
v1.0.0😅
Well, semantic versioning makes an exception for pre-1.x versions that are considered in development/beta, where breaking changes only require a minor, not a major, version increase.
Reference:
https://semver.org/#spec-item-4
Well, we are starting with a new package name, so it's all fine to just reset it to
0.1.0.I would argue however that we should keep it increasing to avoid confusions between
faim-hcs-0.2.5and any futurefaim-ipa-0.2.5that might exist if we don't do that.
Or we can create a new repo faim-ipa and move to code over. After the move we can archive this repo.
Or we can create a new repo faim-ipa and move to code over. After the move we can archive this repo.
Why would you want to do that? GitHub's way of renaming the repo keeps the old URLs working, including links to any commits etc.
I think it would be a shame to lose the link and history between faim-hcs and faim-ipa if we create a new repo.
But I'm not sure I understand: is your concern the presence of v0.x.x tags in this repository? Ideally, we should have used faim-hcs-0.x.x from the beginning, yes. But if we use faim-ipa-0.x.x from now on, it doesn't do any harm, no?
We don't require to have a PyPI artifact for each and every historical tag on this repo.
Sounds all reasonable. Let's stay with this repo and semantic versioning.
After renaming we can do one of the three:
- v0.2.6
- v0.3.0
- faim-ipa-0.1.0
Which would you prefer?
I would prefer faim-ipa-0.3.0 for the tag name, such that the version string reported by hatch version would still be 0.3.0, right?
We don't use the version string anywhere else (since it's computed by hatch-vcs), do we?
I like faim-ipa-0.3.0 and would expect that it works as you describe. Let's see 