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
* GH-597: code and tests established; some new features or work style used: no_share_test wider use
* GH-597: little corrections and formatting
* GH-597: auto review
* GH-597: cosmetics, added a few places with logs
* GH-597: A rookie mistake :) not running and so forgetting integration tests
* update Practice with reference to version & QA
* update practice with version release info
* DRAFT: Update docs/branch (#133)
* Update node top level README
add list of component README files for easy navigation
* Added reference to UI-Interface-Interface
Added reference to UI-Interface-Interface document that lives in the Node repo main folder
* Update README.md
* Delete SHRD-faucet
This is no longer usable and is not connected to the MASQ token contracts
* Update to blockchain service details
Update to blockchain service details about Polygon, testnets, Alchemy
also removed old images
* wording and formattting
* update LICENSE
updated with corrected copyright for MASQ, and added info regarding previous codebase being removed from GitHub and original repo disappeared
* Update Practice with QA blurb
Thanks Stew
* adjust copyright
* remove old DNS doc
* remove old DNS doc
* remove old DNS doc
* delete old faucet info
* updated with component readmes
* remove old logo
* remove old logo2
* Create brand-guidelines.md
* add masq logos
* remove to move logos
* add masq logos
* added masq logo to readme
* GH-597: backup; closely before finishing / fixed an old issue with annoying 'Send' requirement; introducet a new concept of an arbitrary_id_stamp for testing specific situations
* GH-597: finished the concept of ArbitraryIdStamp
* GH-597: updated github yml files; the release one is now more optimized
* GH-597: last polishing before another review
* GH-597: second review addressed
* update from reviews
* update and copyright bump
* copyright bump [skip ci]
[skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* copyright bump [skip ci]
* docs/contributing-plus-cleanup: last polishment
* GH-597: a little correction in docs
* GH-597: fixed a labile test in WebsocketSuperwisor and added an explanation of an unclear solution around there too
* GH-597: removing unknown extern crate usage
* GH-597: trying to get the release build for Node working properly
* GH-597: removing an optimized build script because of an issue on Mac; we don't know how to fix that at the moment
Co-authored-by: Bert <[email protected]>
Co-authored-by: KauriHero <[email protected]>
Copy file name to clipboardexpand all lines: PRACTICE.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -203,16 +203,16 @@ In the future, the team may determine that individual components within the code
203
203
204
204
### Steps for Creating and Tagging the Next Version
205
205
206
-
Currently, the tag is expected to be just a lightweight tag following semver format.
207
-
208
206
The developer should follow these steps to complete the git tag before a repo admin is to merge into `master`
209
207
210
208
-[ ] First acquire an agreement from the Product Owner that your branch (in your open PR) is going to enclose the current, pending release.
211
209
-[ ] Your code in your branch should appear errorless in Actions (it's passed all checks) and also it's satisfied all reviews, so is approved by the reviewer.
212
210
-[ ] Create a tag to the HEAD commit of your branch with the previously agreed version number. If you do that locally on your machine you may want to use e.g.:
213
211
```
214
-
git tag v0.6.1
215
-
212
+
git tag v0.6.1 -m ""
213
+
```
214
+
_Currently, we prefer the style with an empty annotation instead of the so-called lightweight tag because this way we can prevent the message of the last commit to be displayed together with the tag. It's possible that the message would be quite irrelevant to the complete release itself. We may decide to implement a release changelog that could fill that empty space by a good description in the future._
215
+
```
216
216
git push origin v0.6.1
217
217
```
218
218
-[ ] The last step should cause a new trigger of a run in Actions, this time with a different workflow than usual, producing official release binaries.
0 commit comments