Add impact assessment checklist

installer/docs/CHANGE.md

@@ -0,0 +1,72 @@
+# Change Impact Assessment
+
+This document serves as a checklist to assess the impact of changes. It should be used during the
+design and validation stages of the development process to ensure that all aspects of a change's
+potential impact are known.
+
+This document is ordered based on the [Appliance
+Lifecycle](https://github.com/vmware/vic-product/blob/master/installer/SUPPORT.md#appliance-lifecycle)
+with the addition of development related stages.
+
+## Impact Assessment
+
+### Development
+
+- [ ] Design document needed?
+- [ ] User documentation
+- [ ] Updated appliance-support.sh
+- [ ] Updated SUPPORT.md
+- [ ] Technical debt? New issue opened to address debt?
+- [ ] Integration with components
+- [ ] Updated INTEGRATION.md and existing integration documentation
+- [ ] Conforms to [VIC Appliance Design](DESIGN.md)
+
+### Testing
+
+- [ ] Test plan created or updated
+- [ ] Unit testing
+- [ ] Integration testing
+- [ ] Tests added in CI
+
+### Release
+
+- [ ] Process documented in RELEASE.md
+- [ ] Versioning
+- [ ] CI artifact upload
+- [ ] Automated release process
+
+### Deployment Stage
+
+- [ ] User experience
+- [ ] Documentation updates for customizations
+- [ ] Deployment with static IP
+- [ ] Deployment with user provided TLS certificate
+
+### Boot Stage
+
+- [ ] User experience
+- [ ] Account for diverse network configurations
+
+### Initialization Stage
+
+- [ ] User experience
+- [ ] PSC integration, internal and external PSC
+- [ ] Getting Started Page
+
+### Running Stage
+
+- [ ] User experience
+
+### Appliance Upgrade Stage
+
+- [ ] User experience
+- [ ] VIC appliance upgrade
+- [ ] Tested valid upgrade paths
+- [ ] Cleanup from previous upgrade operations
+- [ ] Upgrade interaction with Admiral
+- [ ] Upgrade interaction with Harbor
+- [ ] Upgrade documentation
+
+## Additional Information
+
+- [VIC Appliance Design](https://github.com/vmware/vic-product/blob/master/installer/DESIGN.md)

installer/docs/RELEASE.md

@@ -38,7 +38,7 @@ git push upstream
 ## Tagging
 
 On the master branch, tag the commit for the first release candidate. On the
-subsequent commit, tag `dev` for ongoing development.  For example, if the
+following commit, tag `dev` for ongoing development.  For example, if the
 current release is `v1.2.0`, the first release candidate will be `v1.2.0-rc1` and
 the tag for ongoing development will be `v1.3.0-dev`.
 
@@ -52,6 +52,16 @@ git tag -a v1.2.0-rc1 aaaaaaa
 git push upstream v1.2.0-rc1
 ```
 
+Tag `dev` on the release branch after a release. For example, if `v1.2.0` was tagged on
+`/releases/1.2.0` and there is work for `v1.2.1`, on the following commit, tag `v1.2.1-dev`.
+
+```
+git remote update
+git checkout upstream/releases/1.2.0
+git tag -a v1.2.1-dev bbbbbbb
+git push upstream v1.2.1-dev
+```
+
 
 ## Building Release