pytorch-grad-cam icon indicating copy to clipboard operation
pytorch-grad-cam copied to clipboard

Provide releases or tags

Open sammlapp opened this issue 1 year ago • 2 comments

Hi, it would be great if the repository occasionally tagged a version, since the API changes frequently. For instance, knowing that you have code working with tag 0.1.0 means you can re-install that version to ensure your code still works in the future.

sammlapp avatar Aug 30 '24 17:08 sammlapp

Hi, great idea.

Do you know what is the best practice of tags when there is also a pypi version. Should there be a tag for every new version released on pypi ?

jacobgil avatar Aug 31 '24 17:08 jacobgil

Yes, generally you can create more tags than releases but you should have a unique tag for each release. "Semantic versioning" provides a nice guideline in which you have major.minor.patch versions corresponding to PyPi releases, and potentially other tags for more incremental changes.

quoting that doc:

The idea of semantic versioning (or SemVer) is to use 3-part version numbers, major.minor.patch, where the project author increments:

major when they make incompatible API changes,

minor when they add functionality in a backwards-compatible manner, and

patch, when they make backwards-compatible bug fixes.

I believe it's considered ok (by whom? not sure) to have breaking changes (not backwards compatible) in the minor releases for versions <1.0.0, for instance 0.2.0 might introduce breaking changes compared to 0.1.6, but 1.2.0 should not introduce breaking changes compared to 1.1.6.

sammlapp avatar Sep 04 '24 14:09 sammlapp