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
At Karabo meeting today [22-08-2024] there were some discussions about changing release management. Previously, we've just increased the minor version +1 each month, is sth like a mix between serial, semantic and calendar versioning according to Python packaging user guide. I don't think it makes sense to arbitrarily going up to 1.0.0 without agreeing on versioning management & because 1.0.0 defines the public API. I think one of the following would make sense:
Semantic versioning: Makes it clear and easy for users what to expect if version numbers changed (if we stick strictly to the specification). To follow semantic versioning, we should also consider our API and define what's public and what isn't to determine new versions. I think it would be a good practice to prefix-underscore each and every public importable object (variable, function, class, module & maybe directory?) which is not considered as public API. Strict semantic versioning specification is depicted in semantic versioning 2.0.0.
Calendar versioning: Makes versioning management very easy, but at a disadvantage of any user. You never know if there are breaking changes or not.
I personally tend more to semantic versioning because I consider it way more user-friendly for Python packages. I also don't consider the overhead as too much as long as we don't care how many major releases there are.
The text was updated successfully, but these errors were encountered:
At Karabo meeting today [22-08-2024] there were some discussions about changing release management. Previously, we've just increased the minor version +1 each month, is sth like a mix between serial, semantic and calendar versioning according to Python packaging user guide. I don't think it makes sense to arbitrarily going up to 1.0.0 without agreeing on versioning management & because 1.0.0 defines the public API. I think one of the following would make sense:
I personally tend more to semantic versioning because I consider it way more user-friendly for Python packages. I also don't consider the overhead as too much as long as we don't care how many major releases there are.
The text was updated successfully, but these errors were encountered: