Conversation
| ## Release Managament | ||
|
|
||
| - Starting with `1.0.0` all future releases will follow semver semantics: | ||
|
|
There was a problem hiding this comment.
Relevant changes start here. All the rest is linter changes.
| - merge the PR do develop | ||
| - locally checkout to develop | ||
| - release the new version to npm | ||
| - use new version in your PR in the Daedalus |
There was a problem hiding this comment.
Relevant changes end here. All the rest is linter changes.
renanvalentin
left a comment
There was a problem hiding this comment.
hey @szymonmaslowski i left a few questions regarding the temporary release/branch.
README.md
Outdated
| - checkout to your branch: | ||
| - change the version in package json to `[current version]-next.x` (only add the -next.X suffix keeping the current version) | ||
| - publish the version under the next tag | ||
| - **don't push the version change to upstream** |
There was a problem hiding this comment.
@szymonmaslowski could you please elaborate on this one? What could happen in case we push ?
There was a problem hiding this comment.
Nothing 😂 Maybe it should be rephrased to you don't need to push the version change to upstream as you will be changing it anyway, what do you think?
README.md
Outdated
| 2. Once your code is ready to be tested in Daedalus, you [publish a temporary release](#how-to-publish-a-temporary-release): | ||
|
|
||
| - checkout to your branch: | ||
| - change the version in package json to `[current version]-next.x` (only add the -next.X suffix keeping the current version) |
There was a problem hiding this comment.
Shouldn't the x version be increased as well?
There was a problem hiding this comment.
For the x it should be the first free number (as there could be already a next version released). However this is explained in the "How to publish a temporary release" section which is linked above. I think there is no need to mention it also here. What is your opinion?
Added do the README file a new release flow we agreed on during our recent dev meetings session.
Please search two of my comments pointing out relevant changes as the pre-commit linter hook applied formatting changes unrelevant to the actual release flow documentation.