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
* 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
* 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
Co-authored-by: KauriHero <[email protected]>
Co-authored-by: Bert <[email protected]>
Co-authored-by: Bert <[email protected]>
Copy file name to clipboardExpand all lines: PRACTICE.md
+62-1Lines changed: 62 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -157,5 +157,66 @@ Keep close track of both of these processes so that you can answer any questions
157
157
If the pull request does not pass review or testing, you'll be notified and the card will be moved back into
158
158
Awaiting Development, from whence you can reclaim it if you like.
159
159
160
+
Around this tme, there will also be discussion with the core developers and Product Owner to determine what type of version increment will be involved and adding a git tag after the review, QA and merge to master are completed. If there is a planned release version, then the merge commit may be tagged as a pre-release pending a confirmed release version number.
161
+
162
+
Versioning will follow basic semver - vx.x.x and qualifiers if needed, eg. v0.6.0, 0.7.1-rc1, 1.0.0-beta etc
163
+
160
164
## Quality Assurance
161
-
[Somebody who knows QA should fill this in]
165
+
Quality Assurance usually involves software testing - the execution of a software component or system component to evaluate one or more properties of interest.
166
+
167
+
### In general, these properties indicate the extent to which the component or system under test:
168
+
169
+
-[ ] Meets the requirements that guided its design and development
170
+
-[ ] responds correctly to all kinds of inputs
171
+
-[ ] performs its functions within an acceptable time
172
+
-[ ] is sufficiently usable
173
+
-[ ] can be installed and run in its intended environments
174
+
-[ ] achieves the general result its stakeholders desire
175
+
176
+
As the number of possible tests for even simple software components is practically infinite, all software testing uses some strategy to select tests that are feasible for the available time and resources. As a result, software testing typically, but not exclusively, attempts to execute a program or application with the intent of finding failures due to software faults. The job of testing is an iterative process as when one fault is fixed, it can illuminate other failures due to deeper faults, or can even create new ones.
177
+
178
+
Software testing can be conducted as soon as executable software (even if partially complete) exists. The overall approach to software development often determines when and how testing is conducted. For example, in a phased process, most testing occurs after system requirements have been defined and then implemented in testable programs.
179
+
180
+
In the MASQ Network project, the process of QA is triggered when a card is moved into the 'Quality Assurance In Progress' column on our [Card Wall](https://github.com/MASQ-Project/Node/blob/master/COLUMNS.md)
181
+
182
+
The Testing Supervisor or QA Manager is responsible for passing or failing a card based on the feedback from the test team across the different operating systems being supported. Any feedback, bugs or suggestions are communicated to the developer of the card, and another iteration of development, testing and review is completed.
183
+
184
+
CLI-based QA requires some basic command-line knowledge and understanding of the Node software itself.
185
+
186
+
If you would like to contribute to QA testing, and have a good foundational knowledge of CLI, please reach out to our team by [email](mailto:[email protected]) or join our [Discord](https://discord.gg/masq) and tag one of our admins.
187
+
188
+
## Software Versioning
189
+
The determination of versioning will start with a discussion of the core developers and the Product Owner. This will begin towards the end of a card's engineering practice above, most likely during final review and QA steps.
190
+
191
+
Versioning follows basic [semver format](https://semver.org) - view the formal documentation and conventions for reference.
192
+
193
+
The core specifications to be followed are:
194
+
195
+
- Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.
196
+
- A pre-release version MAY be denoted by appending a hyphen and a series of dot separated - Example: 0.7.3-prerelease. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
197
+
198
+
Once the discussion around the development/feature branch or group of branch has finished, there will be a git tag added to the merge commit when all branch in a determined release are passed through QA and merged to `master` by an admin user of the Node repo.
199
+
If a single branch being merged is not determined to be included in an immediate release with version increment, then no git tag is required unless agreed upon by the majority of the team for testing reasons with other parts of software stack such as the Electron MASQ app.
200
+
201
+
If a merging branch qualifies as a patch or minor release version, then prior to merge the developer will add a commit for review that adjusts all the version numbers in the `cargo.toml` files for all the major components within the codebase. This will be important for monitoring QA testing and logging of issues with different release versions in the wild.
202
+
In the future, the team may determine that individual components within the code will have versions independent of each other, e.g. `automap` may be version 0.6.1, while `node` may have version 0.7.2
203
+
204
+
### Steps for Creating and Tagging the Next Version
205
+
206
+
Currently, the tag is expected to be just a lightweight tag following semver format.
207
+
208
+
The developer should follow these steps to complete the git tag before a repo admin is to merge into `master`
209
+
210
+
-[ ] First acquire an agreement from the Product Owner that your branch (in your open PR) is going to enclose the current, pending release.
211
+
-[ ] 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
+
-[ ] 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
+
```
214
+
git tag v0.6.1
215
+
216
+
git push origin v0.6.1
217
+
```
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.
219
+
-[ ] Now the git tag is in place at HEAD commit of your branch, you're finally ready to let the merge button for your PR to `master` be pressed!
220
+
221
+
With the above steps, automated pipelines and CI will build the software binaries for the 3 currently supported Operating Systems (OS) and upload them into an S3 repository to be archived against their version released whenever there is a version increment.
222
+
There will be a designated repo folder in this repository labelled `latest` which will contain the latest versioned binaries for each OS.
0 commit comments