You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: