Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create oip-draft-versioning.md #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Create oip-draft-versioning.md #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions OIPS/oip-draft-versioning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
oip: 4
title: Releases Versioning Specification
author: Francesco Pacella <[email protected]>
discussions-to: -
status: Draft
type: Meta
category -
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest striking category, requires, and replaces from the header, as these are optional and empty.

created: 2018-11-23
requires : -
replaces : -
---

#Releases Versioning Specification
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After heading hashes, there should be a space (e.g., "#Releases" --> "# Releases"), otherwise it is rendered as simple text.


##Simple Summary
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Referring here to standards as per https://semver.org/.
The unique stream of releases has later split into three identifiable streams, which are independent from a release perspective. As the initial releases of the newly identified streams are imminent, the proper standard for release versioning shall be addressed at this point.

##Motivation
We want to be clear, consistent and aligned with standards to facilitate the understanding of our development progresses for everyone.

##Specification
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

a. OpenST latest release version has been 0.9.4. The proposal is to move with next release to 0.10.0 and then from there proceed with common versioning standards (https://semver.org/).
b. BrandedToken stream has been generated by a branch of OpenST for logic purposes, so as the work of this stream is not starting from scratch, but continuing in parallel from OpenST stream, then the next (and first) release version shall be 0.10.0 as well, and then from there proceed with common versioning standards (https://semver.org/).
c. Mosaic stream is fresh and contains new development (exception made for Gateway and Core contracts). Seen the importance of this stream, the versioning shall start from 0.10.0. Same reasoning shall apply for new-born repositories/streams e.g. BLUE

##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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Versioning" --> "versioning" (for consistency)


##Backwards Compatibility
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Versioning" --> "versioning" (for consistency)