@unimelb/pattern-lib-vue 14.5.3 → 14.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/.out/vue.js +2 -2
  2. package/README.md +21 -25
  3. package/package.json +1 -1
package/README.md CHANGED
@@ -143,47 +143,43 @@ For your own sanity, make sure to install your code editor's ESLint and stylelin
143
143
 
144
144
  - Assign the appropriate `pr-` label to every new PR: `pr-major` if it contains a breaking change, `pr-minor` if it adds a new feature, `pr-patch` in all other cases.
145
145
  - Assign issues and PRs to `next-release` as they are resolved/merged.
146
- - Assign additional labels to issues when relevant (e.g. `bug`, `chore`, `feature`, etc.)
146
+ - Assign additional labels to issues when relevant (e.g. `deprecated`, `documentation`, etc.)
147
147
 
148
148
  **At the end of the release sprint:**
149
149
 
150
+ > [!NOTE] > **Note on versioning**: the version number follows the [semver](http://semver.org/) convention `MAJOR.MINOR.PATCH`, where: `MAJOR` corresponds to a breaking change (e.g. a change in a component's markup), `MINOR` to a new feature (e.g. a new component, a new feature for an existing component, etc.), and `PATCH` to a bug fix or under-the-hood change (e.g. code clean-up, performance improvement, etc.)
151
+
150
152
  1. Look at all the PRs that were assigned to `next-release` throughout the sprint and identify the highest-level of change (major, minor or patch). Deduce the next release's version number and rename the milestone accordingly.
151
153
  1. Create a new release notes draft based on the following template: `.github/RELEASE_NOTES_TEMPLATE.md`.
152
154
  1. Write the release notes by going through all the issues and PRs assigned to the milestone.
153
- 1. Deploy to production (cf. next section).
155
+ 1. Deploy to production:
156
+ 1. Bump the `version` number in `package.json` (cf. note below).
157
+ 1. Commit the version change to the `dev` branch.
158
+ 1. Create a pull request to merge the `dev` branch into `master` - e.g. "Deploy v1.0.1".
159
+ 1. Wait for the mandatory checks to pass then select `Create a merge commit`
154
160
  1. Once the library and documentation sites are deployed, publish the release notes and close the milestone.
155
- 1. Share the ZenHub milestone report with stakeholders.
156
-
157
- **See more Notes about the release process in the release.md section in docs:**
158
- [Docs section](https://github.com/unimelb/pattern-lib/tree/master/docs)
159
-
160
- ## Deployment
161
-
162
- To deploy to production:
163
-
164
- 1. Bump the `version` number in `package.json` (cf. note below).
165
- 1. Commit the version change to the `dev` branch.
166
- 1. Create a pull request to merge the `dev` branch into `master` - e.g. "Deploy v1.0.1".
167
- 1. Wait for the mandatory checks to pass then select `Create a merge commit`
161
+ 1. Share the release on the `design-systems` slack channel using the following template:
168
162
 
169
- Github Actions then automatically builds the library and syncs the output files to S3. If the version you're deploying had been previously deployed, you'll need to invalidate the files on the CDN (AWS Cloudfront) or wait a day or so for this to happen automatically. Once the library is deployed, follow the release process below.
163
+ ```
164
+ @channel new `gen2` version `vx.x.x` is out: https://github.com/unimelb/pattern-lib/releases/tag/vx.x.x
165
+ ```
170
166
 
171
- > **Note on versioning**: the version number follows the [semver](http://semver.org/) convention `MAJOR.MINOR.PATCH`, where: `MAJOR` corresponds to a breaking change (e.g. a change in a component's markup), `MINOR` to a new feature (e.g. a new component, a new feature for an existing component, etc.), and `PATCH` to a bug fix or under-the-hood change (e.g. code clean-up, performance improvement, etc.)
167
+ > [!TIP]
168
+ > Github Actions then automatically builds the library and syncs the output files to S3. If the version you're deploying had been previously deployed, you'll need to invalidate the files on the CDN (AWS Cloudfront) or wait a day or so for this to happen automatically. Once the library is deployed, follow the release process below.
172
169
 
173
170
  ### Semi-automatic deployment to dev
174
171
 
175
172
  Pre-release builds can be created like this (using the git pre-push hook behind the scenes):
176
173
 
174
+ > [!NOTE] > **Note on pre-release versions**: These are legitimate [semver](http://semver.org/) versions. They have the format MAJOR.MINOR.PATCH-beta.NUMBER. **Only** these pre-release versions will be published on `dev`.
175
+
177
176
  1. Check out a clean `dev` branch
178
- 1. in bash `git push`
179
- - This will increment the pre-release version number and make a commit to your local repository
177
+ 1. in bash `git push` - this will increment the pre-release version number and make a commit to your local repository
180
178
  1. in bash `git push` again
181
- - You will be prompted that this will trigger a build. Answer 'y'
182
- - This will push (only) your version number change commit to the remote `dev` repo
179
+ - You will be prompted that this will trigger a build. Answer `y`
180
+ - This will push (only) your version number change commit to the remote `dev` repo
183
181
  1. After the normal checks a build with the new version will be triggered by Github Actions
184
182
 
185
- > **Note on pre-release versions**: These are legitimate [semver](http://semver.org/) versions. They have the format MAJOR.MINOR.PATCH-beta.NUMBER. **Only** these pre-release versions will be published on `dev`.
186
-
187
183
  ## Testing
188
184
 
189
185
  ### Testing Pull-requests
@@ -218,7 +214,7 @@ Recommended mobile devices for testing:
218
214
 
219
215
  ### Visual snapshot testing
220
216
 
221
- You can run visual snapshot testing using `yarn test:snapshots`. This compares your changes against the latest visual snapshot. Failed snapshot tests will show a visual diff comparison in `snapshots/__tests__/__image_snapshots__/__diff_output__`.
217
+ You can run visual snapshot testing using `yarn test:snapshots`. This compares your changes against the latest visual snapshot. Failed snapshot tests will show a visual diff comparison in `snapshots/__tests__/__image_snapshots__/__diff_output__`.
222
218
 
223
219
  If you wish to update the snapshots with your changes run `yarn test:e2e:updatesnapshots`.
224
220
 
@@ -235,4 +231,4 @@ If you wish to update the snapshots with your changes run `yarn test:e2e:updates
235
231
  - [University Home Page](https://unimelb.edu.au)
236
232
  - [About Us](https://about.unimelb.edu.au)
237
233
  - [Brand Hub](https://brandhub.unimelb.edu.au)
238
- - [MSpace](https://mspace.unimelb.edu.au)
234
+ - [MSpace](https://mspace.unimelb.edu.au)
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@unimelb/pattern-lib-vue",
3
3
  "description": "A complete design system for the University of Melbourne.",
4
- "version": "14.5.3",
4
+ "version": "14.6.0",
5
5
  "repository": {
6
6
  "type": "git",
7
7
  "url": "https://github.com/unimelb/pattern-lib.git"