Less unnecessary text
@@ -1,12 +1,3 @@
|
||||
### Run unit tests
|
||||
Start with running unit tests in IE9 (with open developer console), IE10, IE11, Edge, latest Safari, latest Chrome and latest Firefox and make sure all tests pass before the release process is started
|
||||
|
||||
For IE 9 the following errors are acceptable:
|
||||
* `Error: Access is denied.` errors for CORS requests
|
||||
* `Uncaught error outside test suite: Error: 'io' is undefined (http://my-host:3000/test/loader.js:21)`
|
||||
|
||||
Remember to open the developer console (hit `F12`) when running tests in IE9 otherwise you will see a lot of errors like `console is not defined`.
|
||||
|
||||
### Create a release branch
|
||||
|
||||
The release process involves a couple changes to the repository: updating the version number in package.json and adding a changelog. In order to make these release-related changes, create a branch in your repository clone. Note that all the examples below use 3.1.0 as the release version (and 3.0.0 as the previous release). You'll want to use the appropriate version numbers for the release you're working toward.
|
||||
@@ -15,7 +6,7 @@ The release process involves a couple changes to the repository: updating the ve
|
||||
|
||||
### Create a changelog
|
||||
|
||||
Create a changelog for all merges to master since the previous release (see the note below about a potential [race condition](#race-condition) here). You'll want to create a log for all changes since the previous release and name the resulting file like the target release.
|
||||
Create a changelog for all merges to master since the previous release. You'll want to create a log for all changes since the previous release and name the resulting file like the target release.
|
||||
|
||||
./tasks/changelog.sh v3.0.0.. >> changelog/v3.1.0.md
|
||||
|
||||
@@ -136,11 +127,6 @@ Tweet with the openlayers account, something like:
|
||||
OpenLayers v3.12.0 is out! Thanks to everyone who contributed. https://github.com/openlayers/openlayers/releases/tag/v3.1.0
|
||||
```
|
||||
|
||||
### Notes
|
||||
|
||||
<a name="race-condition"></a>
|
||||
Note that there is a potential race condition related to creating a changelog before a release is tagged. This could be avoided by generating the changelog after tagging the release. However, since we already need to make a change to the repository for the release (updating the version in package.json), the changelog creation step is included with this change for convenience. There aren't serious consequences associated with missing an entry in the changelog, so this should be an acceptable tradeoff.
|
||||
|
||||
### Patch releases
|
||||
|
||||
For a patch release, the process is basically the same as for a minor release. The significant difference is that you want to create a new branch from the minor tag. For example:
|
||||
|
||||
Reference in New Issue
Block a user