Skip to content

Steps for releases #23

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

Open
gulshanvasnani wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Steps for releases #23

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
185a376
Added steps for releases
gulshanvasnani Apr 16, 2019
a3f908b
Added link to JLP project
gulshanvasnani Apr 24, 2019
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
28 changes: 28 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -157,3 +157,31 @@ This section applies to Solidity and JavaScript projects alike.
[soliumrc]: ./.soliumrc.json
[travisci]: https://travis-ci.org/
[webpack]: https://webpack.js.org/

Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

Please move the release process section above the reference link definitions—we want the link definitions to stay at the bottom of the doc.

## Release Process
Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

Did you have any thoughts on the time/interval aspect proposed in #14? Certain things that must be true in relation to the sprint?

Copy link
Contributor Author

@gulshanvasnani gulshanvasnani Apr 24, 2019

Choose a reason for hiding this comment

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

I was thinking that we can design our sprints in such a way that after every couple of sprints, we release alpha/beta versions.
What do you think ?


* First version to be released is alpha version, followed by beta version.
Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

Could you propose definitions or some other way(s) to distinguish alpha from beta (and the increments, e.g., alpha.alphaversion vs alpha.<alphaversion+1>)?

Copy link
Contributor Author

@gulshanvasnani gulshanvasnani Apr 24, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

Alpha release should be done when the feature we are completing developing is incomplete or partially complete.
Beta release should be done when the feature is complete and all the development is done but there are possibilities that it could contain some bugs.

Copy link
Contributor

@schemar schemar Apr 24, 2019

Choose a reason for hiding this comment

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

So we can only have a release when we can rule out the possibility of having a bug? 🧐

Copy link
Contributor

@jasonklein jasonklein Apr 24, 2019

Choose a reason for hiding this comment

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

@gulshanvasnani: perhaps it would be useful to distinguish between a tag and a release (tag without pre-release identifiers like alpha.alphaversion + release notes)?

So, perhaps the following changes:

  • If alpha/beta version is to be released tagged, then the tag name should include alpha/beta as per the naming convention mentioned.

  • Release For commits which have been reviewed by external auditor, a rcversion for it should be released tagged

@schemar: I expect we only release when we have high confidence there are no bugs (that are critical and that we intend to fix before releasing), but we tag as appropriate to reflect the contents and/or understanding of the commit per our guidelines. All releases include tags but not all tags are part of releases.

Thoughts?

* 
Naming convention followed for alpha and beta version is `x.y.z-alpha.alphaversion` and `x.y.z-beta.betaversion`. The value of alpha version/beta version should be incremental starting from 1.
**Example :**

1. Consider the version to be released is 0.9.0. If we want to release alpha version for it, then the name of the version should be 0.9.0-alpha.1 and if we want to release beta version then the name for it should be 0.9.0-beta.1 .

* Naming convention for hotfix branch should be hotfix-x.y.z where x.y represents the release version number where the bug is found and z represents incremental patch version for the release starting from 1.
* Branching should accord with Gitflow.

1. For each version to be released(except hotfix release), below steps should be followed :
* Create branch release-x.y, where x and y represents the version numbers, from develop.
Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

What are your thoughts on what determines moving from develop to release-x.y?

Copy link
Contributor Author

@gulshanvasnani gulshanvasnani Apr 24, 2019

Choose a reason for hiding this comment

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

We should create release-x.y from develop when we are about to release alpha versions.

* Create a tag from release-x.y. If alpha/beta version is to be released then the tag name should include alpha/beta as per the naming convention mentioned.
* Integrate and test the alpha/beta version in [JLP](https://github.com/OpenST/JLP).
* Organise external security audits, once everything in integration works fine.
* Release which have been reviewed by external auditor, a rcversion for it should be released. Naming convention for rcversion is `x.y.z-rc.rcversion`. The value of `rcversion` is incremental starting from 1.
* We should then merge the branch release-x.y to develop and master branches.
Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

Can you provide some thoughts on how we decide to go from rcversion to releasing on master and develop?

Copy link
Contributor Author

@gulshanvasnani gulshanvasnani Apr 24, 2019

Choose a reason for hiding this comment

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

All the issues raised by auditors are addressed and testing is done, then we should merge release-x.y to develop and master branches.

Copy link
Contributor

@jasonklein jasonklein Apr 24, 2019

Choose a reason for hiding this comment

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

All the issues raised by auditors are addressed and testing is done, then we should merge release-x.y to develop and master branches.

@gulshanvasnani: works for me, except I would narrow the scope from "all the issues" raised by auditors to those issues raised by auditors that we have decided to address in the given release.

* To release-x.y, create a tag named as x.y.0 and also write the release notes.

2. For each hotfix version to be released, below steps should be followed :
Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

As above, please note that branching should align with Gitflow.

* Create a branch from master if the bug is in the current released version.Otherwise create a branch from the tag where the bug is found. Name of the branch should be as mentioned above.
* Commit the fix to the hotfix branch.
* After committing, test the hotfix in [JLP](https://github.com/OpenST/JLP).
* Merge the hotfix branch to master and develop. If the release branch currently exists, then the hotfix branch should be merged into that release branch instead of develop.
Copy link
Contributor

@jasonklein jasonklein Apr 23, 2019

Choose a reason for hiding this comment

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

Are you able to define what goes into hotfix releases? I think it would be helpful to distinguish between a fix that is released straight to master vs a fix that gets to master through the normal release flow, unless your proposal is that all bug fixes should be treated as hot fixes.

I would suggest defining it earlier than L184, but my comment is here because it's the merging directly to master that is consequential.

Copy link
Contributor Author

@gulshanvasnani gulshanvasnani Apr 24, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

When a bug is found in current release of the product then to provide a fix to it, we should release a hotfix. It should be merged to master directly to avoid it accidentally getting lost during upcoming releases.

* Create a tag from master and write release notes. Tag naming convention should be as per [semver](https://semver.org/).