Check-in [5859c5acc4]

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Undo the additional branch.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | wip-springcoat-bringup
Files: files | file ages | folders
SHA1: 5859c5acc476177a3327e7f165138c0b5317e48b
User & Date: stephanie.gawroriski 2020-05-10 19:11:37
Context
2020-05-10
20:04
Un-deprecate API_LEVEL but instead have it be used to detect if the execution engine is too old. check-in: a738e4fa50 user: stephanie.gawroriski tags: wip-springcoat-bringup
19:11
Undo the additional branch. check-in: 5859c5acc4 user: stephanie.gawroriski tags: wip-springcoat-bringup
19:05
Update on notes. check-in: 4081e87c3f user: stephanie.gawroriski tags: wip-springcoat-bringup
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to developer-guide.mkd.

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

 * Update the changelog with the planned release date if it is known at the
   time, otherwise it is not known.
 * Fork the branch and make a new branch from `trunk` for the release to
   be done, an example would be `release-0.2.x`.
 * In the new `release-0.2.x` branch, update the version numbers in the
   appropriate places so things are updated.
 * When a release is to be made, update the version numbers within the
   branch then merge that into the `stable` branch.
 * Tag the merged `stable` commit as `0.2.0` or an increasing release version
   (example: `0.2.1`) for each increasing release.
 * Do all the common release stuff.
 * While in `trunk`, do the following:
   * The development version can be bumped in which case
     the version will be incremented by two and will be odd (3, 5, 7, etc.).
   * Add the next version to the changelog, so that it may be updated when
     there is a new major change.







<
<
|







16
17
18
19
20
21
22


23
24
25
26
27
28
29
30

 * Update the changelog with the planned release date if it is known at the
   time, otherwise it is not known.
 * Fork the branch and make a new branch from `trunk` for the release to
   be done, an example would be `release-0.2.x`.
 * In the new `release-0.2.x` branch, update the version numbers in the
   appropriate places so things are updated.


 * Tag the commit as `0.2.0` or an increasing release version
   (example: `0.2.1`) for each increasing release.
 * Do all the common release stuff.
 * While in `trunk`, do the following:
   * The development version can be bumped in which case
     the version will be incremented by two and will be odd (3, 5, 7, etc.).
   * Add the next version to the changelog, so that it may be updated when
     there is a new major change.