search

fmi-faim / faim-ipa

A collection of Image Processing and Analysis (IPA) functions used at the Facility for Advanced Imaging and Microscopy (FAIM)
BSD 3-Clause "New" or "Revised" License
9 stars 6 forks source link

Rename repo to faim-ipa #113

Closed tibuch closed 7 months ago

tibuch commented 7 months ago

The name faim-hcs is not representative anymore. We should rename the repo to faim-ipa (image processing and analysis).

tibuch commented 7 months ago

@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/

imagejan commented 7 months ago

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.

tibuch commented 7 months ago

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 :sweat_smile:

Maybe we can do some mix 2024.04_patch? Or prefix it with ipa-0.1.0?

imagejan commented 7 months ago

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.

imagejan commented 7 months ago

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

tibuch commented 7 months ago

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.

Or we can create a new repo faim-ipa and move to code over. After the move we can archive this repo.

imagejan commented 7 months ago

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.

tibuch commented 7 months ago

Sounds all reasonable. Let's stay with this repo and semantic versioning.

After renaming we can do one of the three:

Which would you prefer?

imagejan commented 7 months ago

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?

tibuch commented 7 months ago

I like faim-ipa-0.3.0 and would expect that it works as you describe. Let's see :shipit:

tibuch commented 7 months ago

https://pypi.org/project/faim-ipa/