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
Is your feature request related to a problem? Please describe.
The version on the release branches always includes the third digit (aka micro or patch), so development versions are then 8.0.1dev.
However, the main branch with the development-only odd minor version numbers never gets a micro, e.g., 8.1dev, version which is inconsistent.
The missing third number also open room for inconsistencies in representing the version representation. It is 8.3dev or 8.3.dev?
Describe the solution you'd like
The main branch should add 0 to the version, i.e., 8.3.0dev. The 0 (and dev) will be always there.
Describe alternatives you've considered
Keep the current state, but be consistent in 8.3dev versus 8.3.dev. (Not realistic and does not address inconsistencies with release branches.)
Replace dev by 0, i.e., 8.3.0. The odd minor says that it is a development version. (In odds common versioning schemes which add some type of suffix.)
Drop the version idea completely from main and somehow have it version-less with commit has used everywhere. (Too difficult to implement.)
The main branch has the next version to be branched from it, so now it would be 8.3.0dev or 8.4.0dev. This includes either not using the odd-even distinction and treating odd minor versions (main is 8.3.0dev) the same as even ones or skipping odd minor versions completely (main is 8.4.0dev) to keep the practice just for releases. (Although this seems like a big change, it is only change in procedure and it actually greatly simplifies the numbering procedure. It may also allow us to use some existing tooling to automate things and, e.g., improve the suffixes.)
Release previews from the main branch, so keep on main whatever is the next version to be released from that code base, but keeping the odd-even distinction. The micro version than increases as needed. (The would need an easy release procedure to be feasible, but releasing unstable previews directly from main is not incompatible with the preferred solution of just including 0 right now.)
Additional context
We had several consistency issues recently and the missing micro release complicates the procedure (now captured in a script in #2331).
This issue is partially based on my previous comment: #1583 (comment).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The version on the release branches always includes the third digit (aka micro or patch), so development versions are then 8.0.1dev.
However, the main branch with the development-only odd minor version numbers never gets a micro, e.g., 8.1dev, version which is inconsistent.
The missing third number also open room for inconsistencies in representing the version representation. It is 8.3dev or 8.3.dev?
Describe the solution you'd like
The main branch should add 0 to the version, i.e., 8.3.0dev. The 0 (and dev) will be always there.
Describe alternatives you've considered
Additional context
We had several consistency issues recently and the missing micro release complicates the procedure (now captured in a script in #2331).
This issue is partially based on my previous comment: #1583 (comment).
The text was updated successfully, but these errors were encountered: