Conversation
initial draft
|
Love it ❤️ |
jasonklein
left a comment
jasonklein
left a comment
There was a problem hiding this comment.
Thanks for this OIP! I've requested some changes.
| discussions-to: - | ||
| status: Draft | ||
| type: Meta | ||
| category - |
There was a problem hiding this comment.
Suggest striking category, requires, and replaces from the header, as these are optional and empty.
| replaces : - | ||
| --- | ||
|
|
||
| #Releases Versioning Specification |
There was a problem hiding this comment.
After heading hashes, there should be a space (e.g., "#Releases" --> "# Releases"), otherwise it is rendered as simple text.
| We need to establish a new consistent versioning standard for OpenST releases going forward and agree on the versioning logic for Mosaic and BrandedToken and other repositories releases as well. | ||
|
|
||
| ##Abstract | ||
| We started in November 2017 with an initial unique release stream, being OpenST. The first version was released under the name of 0.9.0. The versions that followed did not followed the common standard for releases, utilizing PATCH level to actually address MINOR level releases. |
There was a problem hiding this comment.
Line breaks between new lines of simple text are not rendered in MD output—if the line breaks in this abstract section are meant to place each sentence into its own paragraph, empty lines should be added between.
| ##Rationale | ||
| - An solution is needed in order to proceed further. | ||
| - This setup allows to potentially increase the frequency of intra-releases as we will be able to address PATCHES with the third position element of the versioning. | ||
| - This Versioning standard will be in line with audience expectations versioning-wise when approaching our project. |
There was a problem hiding this comment.
"Versioning" --> "versioning" (for consistency)
| We cannot change the past of the versioning for OpenST, but our mission is to clarify it going forward. | ||
|
|
||
| ##Implementation | ||
| Once the Versioning standard will be agreed, it will be then applied in reality at the moment of the release and for outside communication to the public and different stakeholders. |
There was a problem hiding this comment.
"Versioning" --> "versioning" (for consistency)
| ##Motivation | ||
| We want to be clear, consistent and aligned with standards to facilitate the understanding of our development progresses for everyone. | ||
|
|
||
| ##Specification |
There was a problem hiding this comment.
Please also specify the following:
- pre-releases should be additionally identified by "alpha", "rc" (for release candidates), etc. as agreed
- additional identifiers should be cardinally-numbered (e.g., starting with 1), such as "alpha.1", "rc.1"
- a release candidate "is a beta version with potential to be a final product", so should follow, not precede, an alpha
- versions are not prefixed with "v"
- format looks like:
<major>.<minor>.<patch>-<identifier>.<number>, e.g. (0.10.0-alpha.1,0.10.0-rc.1)
The foregoing is specified in the semver documentation and thus does not necessarily need to spelled-out here. However, as some of these are small formatting distinctions that also depart from past practice (see, e.g., https://github.com/OpenSTFoundation/mosaic-contracts/releases/tag/v0.9.3-rc1), I believe there is value to explicit specification in this OIP.
3 participants
initial draft