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
Problem:
Currently, each crate in this repo is independently versioned. This makes it difficult to track issues when users report issues, as we need to ask for the version of every individual crate before we can investigate. This is unnecessary overhead. When we do a release, it is equally hard to "name" the overall release. We have been using the pattern "Release ABC", where ABC is the version of the API crate.
Proposal:
Proposing that we use a single version number(Major.Minor) for all crates in this repo. This would mean that when one crate is updated, all crates would use the same version number (Major.Minor), regardless of whether they had changes or not. Although this could result in “empty” releases for crates without actual changes, such occurrences are extremely rare. A hotfix for a leaf crate (which no other crate depends on) would only update a patch version number, so no need to force a version bump for all other crates, as the proposal is to use uniform Major.Minor for all crates, and patch number could be different if there is a need.
Once we reach the 1.0 release, we can revisit the versioning strategy if necessary. However, unifying the versions now simplifies pre-1.0 development and testing, which is our current focus.
Please share thoughts/feedback on this. If no concerns, I plan to use this approach for the release planned now. (Release was originally planned for earlier this week, but I expect to do it by Monday)
The text was updated successfully, but these errors were encountered:
Problem:
Currently, each crate in this repo is independently versioned. This makes it difficult to track issues when users report issues, as we need to ask for the version of every individual crate before we can investigate. This is unnecessary overhead. When we do a release, it is equally hard to "name" the overall release. We have been using the pattern "Release ABC", where ABC is the version of the API crate.
Proposal:
Proposing that we use a single version number(Major.Minor) for all crates in this repo. This would mean that when one crate is updated, all crates would use the same version number (Major.Minor), regardless of whether they had changes or not. Although this could result in “empty” releases for crates without actual changes, such occurrences are extremely rare. A hotfix for a leaf crate (which no other crate depends on) would only update a patch version number, so no need to force a version bump for all other crates, as the proposal is to use uniform Major.Minor for all crates, and patch number could be different if there is a need.
Once we reach the 1.0 release, we can revisit the versioning strategy if necessary. However, unifying the versions now simplifies pre-1.0 development and testing, which is our current focus.
Please share thoughts/feedback on this. If no concerns, I plan to use this approach for the release planned now. (Release was originally planned for earlier this week, but I expect to do it by Monday)
The text was updated successfully, but these errors were encountered: