Version numbers #2158
Replies: 2 comments 3 replies
-
|
If we feel that calendar versioning is a too drastic departure from the current version name, we could also stick with our current version numbers, but more clearly describe in our documentation what our promises are with regards to backwards compatibility and that those are not quite what semantic versioning implies, though we do our best. We mention semantic versioning e.g. here. |
Beta Was this translation helpful? Give feedback.
-
|
Where do we fall short for semantic versioning? Is that merely a label or documentation problem? Or should we rather clarify for ourselves what we mean by backwards compatibility and when it is broken? |
Beta Was this translation helpful? Give feedback.
-
|
This item in particular: https://semver.org/#spec-item-8 Even if we limit our Public API to the recipe, we are not following it |
Beta Was this translation helpful? Give feedback.
-
|
Are we keeping track of backward compatibility? If not, that's a problem regardless of the numbers we attach. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we try to make only backward compatible changes. Maybe we should add a specific label to pull requests that are not backward compatible and make it easier to find them like that? Also for using when writing the changelog? |
Beta Was this translation helpful? Give feedback.
-
At the moment we try to use semantic versioning, but we find that we cannot strictly follow it for practical reasons. @jvegasbsc proposed switching to calender versioning, as that may better communicate what promises we (do not) make about backwards compatibility.
We discussed this topic at the May 2021 workshop. The general feeling was that people felt that it was nice to have a version starting with
2., because we have a number of papers published that specifically mention this version, but opinions are welcome! Please participate in this discussion if you have an opinion on the topic.Beta Was this translation helpful? Give feedback.
All reactions