From 6f28f16883be9980efa323315d8c7454f43f8f87 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Wed, 29 Apr 2020 11:22:11 -0400 Subject: [PATCH 01/15] Create development-cycle.md --- rfc/development-cycle.md | 205 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) create mode 100644 rfc/development-cycle.md diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md new file mode 100644 index 0000000..b355e73 --- /dev/null +++ b/rfc/development-cycle.md @@ -0,0 +1,205 @@ + +# Jupyter Development Cycle + +**TODO** + +* Look at merging in, I dont think this works on merging in patch/minor up once the + next release has had a prerelease. I think as base we should choose the branch with the most recent release maybe? + +The goal of this document is to outline a development cycle for JupyterLab which makes it very easy to do releases. As [documented in this issue](https://github.com/jupyterlab/jupyterlab/issues/8195), it's currently a quite laborious and specialized process. If we can make releases easier to manage, and push any of the hard work around so it's tackled by the authors of the PRs instead of the release managers, we can release more easily and free up core developer time for other matters. + +This is meant to support our existing release cycles, not change them, but just provide some standardization and tooling to aid us in keeping to them. + +## Assumptions + +I have found it helpful to try to first outline the assumptions of our release and development process. + +Please give feedback on these first. + +You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) spec, having more to do with the relations between the code evolution between multiple versions. They assume we are already following SemVer. + + +**alpha, beta, rc**: Each release goes through some optional number of alpha, beta, and RC release, before the final. For some final release `{x}.{y}.{z}` it can be modeled with this state machine + +1. Start by releasing one of these: + 1. `{x}.{y}.{z}a0` + 2. `{x}.{y}.{z}b0` + 3. `{x}.{y}.{z}rc0` + 4. `{x}.{y}.{z}` +2. Then the next release can be either an increment of the last number or a release of one of the initial following your + release. For example after `{x}.{y}.{z}b10` you could release `{x}.{y}.{z}b11` or `{x}.{y}.{z}rc0` or `{x}.{y}.{z}` (final). + +**Previous Ancestor**: The next increment will be the git ancestor of the previous increment. + +* Patch: `{x}.{y}.{z}` is an ancestor of `{x}.{y}.{z+1}`. +* Minor: `{x}.{y}.0` is an ancestor of `{x}.{y+1}.0`. +* Major: `{x}.0.0` is an ancestor of `{y+1}.0.0`. + +**Single Active**: No commits will be queued up for a release until the previous increment was fully release +(this also falls out of the above assumption). + +* Patch: No commits towards `{x}.{y}.{z}` till `{x}.{y}.{z-1}` final is released. +* Minor: No commits towards `{x}.{y}.0` till `{x}.{y-1}.0` final is released. +* Major: No commits towards `{x}.0.0` till `{x-1}.0.0` final is released. + +The last two mean you have to totally finish release before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. + + +## Branches + +Given these assumptions, we can create a consistent strategy aligning branches to different releases: + +1. Patch: `{x}.{y}.x` branches. +2. Minor: `{x}.x.0` branches. After final release `{x}.{y}.0` create new patch `{x}.{y}.x` branch. +3. Major: `master` branch. After release `{x}.0.0` create new minor `{x}.x.0` branch and new patch `{x}.0.x` branch. + +Each increment has a corresponding "latest" branch for the greatest working version. For example with two branches `2.x.0`, `1.x.0` the "latest" minor branch is `2.x.0`. The latest major branch is always `master`. + +*Note: We could instead have separate branches for each version, but this isn't necessarily if we are going by the **Single Active** assumption above.* + + +## PR Semver Tags + +Each PR should be tagged with one of three tags `semver:patch`, `semver:minor`, `semver:major` before it is merged. We could do this manually or by possibly giving a first guess [using type analysis](https://api-extractor.com/) or some commit message keywords. We should have a bot that blocks merging if one of these is not added. + +## PR Base Branches + +Each pull request should target as it's base branch the latest branch for the corresponding increment. We should have a bot that keeps this up to date ([can change base branch in Github API](https://octokit.github.io/rest.js/v17#pulls-update)). For example if a PR is tagged with `semver:minor` and you have branches `master`, `2.x.0`, `1.x.0`, and `2.1.x` it should be have as its head `2.x.0` because that is the latest minor branch. + + +## PR Backports +Once PR is merged, backport PRs should be opened against all other open branches of the corresponding increment. + +This will likely result in some cases where backports are proposed that are not appropriate, in which case they can be closed. + + +## Branch Merges + +After a release on a branch, a PR should be opened to merge it into the larger increment branch, for minor and patch releases. +The key is to not create a merge if the branch doesn't exist or if this commit wasn't targeting the most recent release. + +* Patch: After a release of `{x}.{y}.{z}` on branch `{x}.{y}.x` a PR should be opened to merge `{x}.{y}.x` into `{x}.x.0` if it exists, otherwise into master if this a patch on the latest minor and latest major, i.e. the last final release on `master` is `{x}.0.0` and the last final release on `{x}.0.x` is `{x}.{y}.0`. +* Minor: After a release of `{x}.{y}.0` on branch `{x}.x.0` a PR should be opened to merge `{x}.x.0` into `master` if the last final release on master is `{x}.0.0`. + + + +## Milestones + +Each branch therefore always has an "active" milestone associated with it, which corresponds to the next final release +on that branch. If we don't wish to make any more releases from a branch, we should delete it. + +Each PR's milestone should reflect active milestone of the branch it targets. + +## Changelog + +Each PR should add or edit a file in a directory full of files corresponding to unreleased changes, [like matplotlib does](https://matplotlib.org/devel/contributing.html#contributing-pull-requests). During a final release, these items are deleted +from that file and compiled to a changelog file for that release. All of these files are included in the master changelog. + +The changelog entries should be kept in chronological order, instead of semver ordering. + + +## Example Branches + +I went back and looked at all our tags since `v1.1.0` to see if I could create a branch diagram for them (using [`gitgraph.js`](https://github.com/nicoespeon/gitgraph.js/)) if we had been using the technique I proposed above. I don't include any commits, besides releases and merges. Also, I designate still open branches by giving them each a final commit at the end. So this would be under the assumption that the only version branches open in the repo are `master`, `2.x.0`, `2.1.x`, and `1.2.x`. ([src](https://codepen.io/saulshanabrook/pen/xxwryBa?editors=1010)). It also supposes that we had a `1.x.0` branch that we deleted after `1.2.0` release. That is why all the later patches to `1.2` are not merged into that branch. If we had left it open, then they would be and we could make another minor release on 1 if we wanted. + +![](https://gist.githubusercontent.com/saulshanabrook/c4cd5b85161ea41b533c1725d72ab510/raw/fb9c9206cd6915166de1c3716a22eddaacef679f/codepen----gitgraph-js-playground%2520(1).svg) + +## Division of labor + +There are many moving parts to the proposal. I thought it would be helpful to lay out what would be the responsibility of the different parties, including the bots. + +The "Bots" section is also a roadmap of what would need to be implemented to move forward on this. + +### Pull request author + +**Semver Label**: Make sure pull request has appropriate semver label. +You can set it by either adding a commit with `semver:patch`, `semever:minor`, or `semver:major`, or setting the label in GitHub. + +**Changelog entry**: Add a new markdown or RST file in `docs/source/changes/new`. Use the current data and some rough title for the filename, so it is unique. If you want it to be under a subheader, make a subdirectory for that. Some common ones are `Bug fixes`, `For developers`, `User-facing changes`. If your change is small, just make it a single bullet in a list. + + +**Milestone**: Don't touch this, it will be set automatically. + +**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, then add `release:backport` tag and set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest semver release is 2.1.2, then use this label and set the base branch to `1.2.x`. + + +### Pull request merger + +**Semver Label**: Verify the correct semver label is applied to the change. + +**Changelog entry**: Verify that any changes add or change an existing changelog entry. + +**Review backports**: After you merge it, review all the backport PRs that were created and merge them if appropriate. Close any that are not relevent. Also for any backports the bot failed to make automatically, make them manually if they are necessary. + +### Release Manager + +To make a release go to {as yet unspecified page we will build} and you will see a list of all the open branches. Each branch will show you the number of commits since the last release on that branch. Also on each branch will be buttons for each of the releases you can make from that branch. Any branch which has a release ongoing (currently running) will show that. You can also delete any version branch from this UI where the last commit was a final version. + + + +### Bots + + +**Semver label**: Whenever a PR has new commits, scan them for the semver label names in the messages, and if it finds any merge it with the existing, choosing the more. Also look at special label like `feature:Bug` (patch) and `feature:Enhancement` (minor). + + +**Semver check**: Fail (and don't allow merging on this failure) on any PR that doesn't have one, and only one, of the `semver:patch`, `semver:minor`, `semver:major` labels. + +**Create backports**: After a PR is merged, that doesn't have a `release:backport` label, create backports for that release. It should target all other branches of the same increment, and add `release:backport` to those PRs: + +* Major: Merging into `master` creates no backports. +* Minor: Merging into `{x}.x.0` creates backports to all other branches `{x'}.x.0`. +* Patch: Merging into `{x}.{y}.x` creates backports to all other branches `{x'}.{y'}.x`. + + +**Update base**: If a PR doesn't have the `release:backport` label, then set the base of the PR to the latest existing branch corresponding to the semver label: + +* Major: Base should be `master` +* Minor: Base should be`{x}.x.0` for largest `x`. +* Patch: Base should be`{x}.{y}.x` for largest `x`, then largest `y`. + +The base should be updated whenever the semver label is updated. + + +**Base check**: Verify that the semver label corresponds to the increment of the branch of the base. + + +**Update/create milestone**: Set the milestone to the next final release of the base branch. Update after every change of base branch and after every commit on the base branch. Create the milestone if it does not exist. + +**Do release**: This should be an action with an API endpoint. It is the most complicated and involved action. It takes place in a number of stages: + +1. Input/pre-release check +2. Bump JS and push release +3. Create python release and test (optional) +4. Push python python release +5. Create new branches and create merge commits (on final release) +7. Create PRs to other repos for new version (on final release) + +It takes three inputs, the branch you are releasing from, whether it's a pre release, and whether to force release without testing. If it is a pre-release, it should be one of `rc`, `beta`, `alpha`. + +Before starting it checks to make sure the branch is version branch and that the pre release is valid. You can skip pre release phases, but you cannot go backwards. +This means if you just did a beta, you cannot do an rc, and if you just did an rc, you cannot do a beta or alpha. + +Next, it will checkout the branch in question and create a clean environment. Then it will run the appropriate `jlpm bumpversion` command (these will need to be updated) to create and publish the packages. + +Then it will publish all the JS packages `npm run publish:all`. + +Next it will run the end to end tests in a clean environment, if we are not doing a force release, (not the normal unit tests. This let's us publish even if these are failing). If these fail it will push what the JS version changes, but not the python one and exit. + +If they succeed, it will upload the wheel to python and push all tags and commits. + +Now, if this was a final release, it has some more work to do! First, it will try to merge this release into another branch, as the "Branch Merging" logic dictates above. Then create new branches according to the "Branches" logic above. Push all of that. + +Then it will open PRs to the cookiecutter repos, if this was the latest release, to update them. + +For any type of release, it will also open a PR against the conda forge repo, to release this version. It will create it on the same branch as the branch we made the release on in JupyterLab. + + +## Open questions + +1. How to deal with granularities of version changes across JS packages? Currently we only [have major version bumps for the packages we need to](https://github.com/jupyterlab/jupyterlab/blob/master/RELEASE.md#js-major-releases). This system doesn't support that, instead bumping everything! How granular do we wanna be? Just for major? Or for minor versions as well? What if a PR is a minor version bump for some packages and patch changes for others? Should we track this? + + +## Further work: + +**Changelog bot**: Bot that helps you auto generate changelog entries from git commits or PR descriptions. Comment `bot:generate-changelog` in the PR to create one from the github issue contents. It will replace/create a changelog file using the title of the PR and the issue number. From 52336d6811dab4f884ed7775a07ad792faea254e Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Wed, 29 Apr 2020 11:53:44 -0400 Subject: [PATCH 02/15] Move changelog question to bottom --- rfc/development-cycle.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index b355e73..7441779 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -1,11 +1,6 @@ # Jupyter Development Cycle -**TODO** - -* Look at merging in, I dont think this works on merging in patch/minor up once the - next release has had a prerelease. I think as base we should choose the branch with the most recent release maybe? - The goal of this document is to outline a development cycle for JupyterLab which makes it very easy to do releases. As [documented in this issue](https://github.com/jupyterlab/jupyterlab/issues/8195), it's currently a quite laborious and specialized process. If we can make releases easier to manage, and push any of the hard work around so it's tackled by the authors of the PRs instead of the release managers, we can release more easily and free up core developer time for other matters. This is meant to support our existing release cycles, not change them, but just provide some standardization and tooling to aid us in keeping to them. @@ -198,7 +193,7 @@ For any type of release, it will also open a PR against the conda forge repo, to ## Open questions 1. How to deal with granularities of version changes across JS packages? Currently we only [have major version bumps for the packages we need to](https://github.com/jupyterlab/jupyterlab/blob/master/RELEASE.md#js-major-releases). This system doesn't support that, instead bumping everything! How granular do we wanna be? Just for major? Or for minor versions as well? What if a PR is a minor version bump for some packages and patch changes for others? Should we track this? - +2. How do we deal with changelogs properly? Where do we deploy them from? ## Further work: From 23e339df20ab430e640a4ebcf2d0b399432191db Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Wed, 29 Apr 2020 12:07:27 -0400 Subject: [PATCH 03/15] Only merge into master! --- rfc/development-cycle.md | 65 ++++++++++++++-------------------------- 1 file changed, 22 insertions(+), 43 deletions(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 7441779..fb0d355 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -39,10 +39,13 @@ You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) sp The last two mean you have to totally finish release before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. +## Strategy -## Branches +Based on these assumption we can create a consistant branching strategy. -Given these assumptions, we can create a consistent strategy aligning branches to different releases: +### Branches + +Each branch should be aligned to different releases: 1. Patch: `{x}.{y}.x` branches. 2. Minor: `{x}.x.0` branches. After final release `{x}.{y}.0` create new patch `{x}.{y}.x` branch. @@ -53,51 +56,40 @@ Each increment has a corresponding "latest" branch for the greatest working vers *Note: We could instead have separate branches for each version, but this isn't necessarily if we are going by the **Single Active** assumption above.* -## PR Semver Tags +### PR Semver Tags Each PR should be tagged with one of three tags `semver:patch`, `semver:minor`, `semver:major` before it is merged. We could do this manually or by possibly giving a first guess [using type analysis](https://api-extractor.com/) or some commit message keywords. We should have a bot that blocks merging if one of these is not added. -## PR Base Branches - -Each pull request should target as it's base branch the latest branch for the corresponding increment. We should have a bot that keeps this up to date ([can change base branch in Github API](https://octokit.github.io/rest.js/v17#pulls-update)). For example if a PR is tagged with `semver:minor` and you have branches `master`, `2.x.0`, `1.x.0`, and `2.1.x` it should be have as its head `2.x.0` because that is the latest minor branch. - - -## PR Backports -Once PR is merged, backport PRs should be opened against all other open branches of the corresponding increment. - -This will likely result in some cases where backports are proposed that are not appropriate, in which case they can be closed. - - -## Branch Merges +If you have change that is *only* a backprt, and should not appear in master, then you can target that branch as the base of this merge. -After a release on a branch, a PR should be opened to merge it into the larger increment branch, for minor and patch releases. -The key is to not create a merge if the branch doesn't exist or if this commit wasn't targeting the most recent release. +### PR Backports +Once a PR is merged into master, backport PRs should be opened against all other open branches of the corresponding increment. +This will likely result in some cases where backports are proposed that are not appropriate, in which case they can be closed. -* Patch: After a release of `{x}.{y}.{z}` on branch `{x}.{y}.x` a PR should be opened to merge `{x}.{y}.x` into `{x}.x.0` if it exists, otherwise into master if this a patch on the latest minor and latest major, i.e. the last final release on `master` is `{x}.0.0` and the last final release on `{x}.0.x` is `{x}.{y}.0`. -* Minor: After a release of `{x}.{y}.0` on branch `{x}.x.0` a PR should be opened to merge `{x}.x.0` into `master` if the last final release on master is `{x}.0.0`. +1. Patch: Backport to all `{x}.{y}.x` branches and all `{x}.x.0` branches. +2. Minor: Backport to all `{x}.x.0` branches. +3. Major: No backports. - -## Milestones +### Milestones Each branch therefore always has an "active" milestone associated with it, which corresponds to the next final release on that branch. If we don't wish to make any more releases from a branch, we should delete it. Each PR's milestone should reflect active milestone of the branch it targets. -## Changelog +### Changelog Each PR should add or edit a file in a directory full of files corresponding to unreleased changes, [like matplotlib does](https://matplotlib.org/devel/contributing.html#contributing-pull-requests). During a final release, these items are deleted from that file and compiled to a changelog file for that release. All of these files are included in the master changelog. The changelog entries should be kept in chronological order, instead of semver ordering. +## Example -## Example Branches - -I went back and looked at all our tags since `v1.1.0` to see if I could create a branch diagram for them (using [`gitgraph.js`](https://github.com/nicoespeon/gitgraph.js/)) if we had been using the technique I proposed above. I don't include any commits, besides releases and merges. Also, I designate still open branches by giving them each a final commit at the end. So this would be under the assumption that the only version branches open in the repo are `master`, `2.x.0`, `2.1.x`, and `1.2.x`. ([src](https://codepen.io/saulshanabrook/pen/xxwryBa?editors=1010)). It also supposes that we had a `1.x.0` branch that we deleted after `1.2.0` release. That is why all the later patches to `1.2` are not merged into that branch. If we had left it open, then they would be and we could make another minor release on 1 if we wanted. +I went back and looked at all our tags since `v1.1.0` to see if I could create a branch diagram for them (using [`gitgraph.js`](https://github.com/nicoespeon/gitgraph.js/)) if we had been using the technique I proposed above. I don't include any commits, besides releases and merges. Also, I designate still open branches by giving them each a final commit at the end. So this would be under the assumption that the only version branches open in the repo are `master`, `2.x.0`, `2.1.x`, and `1.2.x`. ([src](https://codepen.io/saulshanabrook/pen/xxwryBa?editors=1010)). -![](https://gist.githubusercontent.com/saulshanabrook/c4cd5b85161ea41b533c1725d72ab510/raw/fb9c9206cd6915166de1c3716a22eddaacef679f/codepen----gitgraph-js-playground%2520(1).svg) +![](https://gist.githubusercontent.com/saulshanabrook/6d92df6e1872a5560674e097efd4abf3/raw/1e4f533196d24e9db9955dc8c0ba487e0633edc7/codepen----gitgraph-js-playground%2520(2).svg) ## Division of labor @@ -115,7 +107,7 @@ You can set it by either adding a commit with `semver:patch`, `semever:minor`, o **Milestone**: Don't touch this, it will be set automatically. -**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, then add `release:backport` tag and set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest semver release is 2.1.2, then use this label and set the base branch to `1.2.x`. +**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest semver release is 2.1.2, then use this label and set the base branch to `1.2.x`. ### Pull request merger @@ -135,28 +127,15 @@ To make a release go to {as yet unspecified page we will build} and you will see ### Bots -**Semver label**: Whenever a PR has new commits, scan them for the semver label names in the messages, and if it finds any merge it with the existing, choosing the more. Also look at special label like `feature:Bug` (patch) and `feature:Enhancement` (minor). +**Semver label**: Whenever a PR has new commits, scan them for the semver label names in the messages, and if it finds any merge it with the existing, choosing the more breaking. Also look at special label like `feature:Bug` (patch) and `feature:Enhancement` (minor). **Semver check**: Fail (and don't allow merging on this failure) on any PR that doesn't have one, and only one, of the `semver:patch`, `semver:minor`, `semver:major` labels. -**Create backports**: After a PR is merged, that doesn't have a `release:backport` label, create backports for that release. It should target all other branches of the same increment, and add `release:backport` to those PRs: - -* Major: Merging into `master` creates no backports. -* Minor: Merging into `{x}.x.0` creates backports to all other branches `{x'}.x.0`. -* Patch: Merging into `{x}.{y}.x` creates backports to all other branches `{x'}.{y'}.x`. - - -**Update base**: If a PR doesn't have the `release:backport` label, then set the base of the PR to the latest existing branch corresponding to the semver label: - -* Major: Base should be `master` -* Minor: Base should be`{x}.x.0` for largest `x`. -* Patch: Base should be`{x}.{y}.x` for largest `x`, then largest `y`. - -The base should be updated whenever the semver label is updated. +**Create backports**: After a PR is merged into the `master` brnach, create backports for that release. It should target all other branches of the same increment according to the "PR Backports" logic above. -**Base check**: Verify that the semver label corresponds to the increment of the branch of the base. +**Base check**: Verify that the semver label corresponds to the increment of the branch of the base, if it isn't master. **Update/create milestone**: Set the milestone to the next final release of the base branch. Update after every change of base branch and after every commit on the base branch. Create the milestone if it does not exist. From 35e3575367337e5e4e579d79f39bfe5017118ac5 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Fri, 1 May 2020 09:43:35 -0400 Subject: [PATCH 04/15] Bump all JS versions in sync --- rfc/development-cycle.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index fb0d355..7e65ed3 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -39,6 +39,8 @@ You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) sp The last two mean you have to totally finish release before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. +**JavaScript versions In Sync** We are ok always keeping the JS version bumps in sync. Meaning that if we do a major release of the Python package we also do a major release of all JS versions. + ## Strategy Based on these assumption we can create a consistant branching strategy. @@ -171,8 +173,7 @@ For any type of release, it will also open a PR against the conda forge repo, to ## Open questions -1. How to deal with granularities of version changes across JS packages? Currently we only [have major version bumps for the packages we need to](https://github.com/jupyterlab/jupyterlab/blob/master/RELEASE.md#js-major-releases). This system doesn't support that, instead bumping everything! How granular do we wanna be? Just for major? Or for minor versions as well? What if a PR is a minor version bump for some packages and patch changes for others? Should we track this? -2. How do we deal with changelogs properly? Where do we deploy them from? +1. How do we deal with changelogs properly? Where do we deploy them from? ## Further work: From 35a757035f171acbcda5a534c973ff0d2a649310 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 12:01:45 -0400 Subject: [PATCH 05/15] Be more clear that you can have multiple in progress releases on different branches --- rfc/development-cycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 7e65ed3..004f88b 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -37,7 +37,7 @@ You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) sp * Minor: No commits towards `{x}.{y}.0` till `{x}.{y-1}.0` final is released. * Major: No commits towards `{x}.0.0` till `{x-1}.0.0` final is released. -The last two mean you have to totally finish release before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. +The last two mean you have to totally finish a release on one branch before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. However, you could have `1.2.0a0`, `1.1.1a0`, `1.2.0`, then `1.1.1`, because these would be on different branches, `1.x.0` and `1.1.x`. **JavaScript versions In Sync** We are ok always keeping the JS version bumps in sync. Meaning that if we do a major release of the Python package we also do a major release of all JS versions. From cca3718626e33f71e444169d63e554f7ebef7285 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 12:03:36 -0400 Subject: [PATCH 06/15] Add note on extensions supporting multiple major versions --- rfc/development-cycle.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 004f88b..a509f26 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -39,7 +39,7 @@ You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) sp The last two mean you have to totally finish a release on one branch before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. However, you could have `1.2.0a0`, `1.1.1a0`, `1.2.0`, then `1.1.1`, because these would be on different branches, `1.x.0` and `1.1.x`. -**JavaScript versions In Sync** We are ok always keeping the JS version bumps in sync. Meaning that if we do a major release of the Python package we also do a major release of all JS versions. +**JavaScript versions In Sync** We are OK always keeping the JS version bumps in sync. Meaning that if we do a major release of the Python package we also do a major release of all JS versions. ## Strategy @@ -125,6 +125,11 @@ You can set it by either adding a commit with `semver:patch`, `semever:minor`, o To make a release go to {as yet unspecified page we will build} and you will see a list of all the open branches. Each branch will show you the number of commits since the last release on that branch. Also on each branch will be buttons for each of the releases you can make from that branch. Any branch which has a release ongoing (currently running) will show that. You can also delete any version branch from this UI where the last commit was a final version. +### Extension Authors + +Be sure to allow multiple major versions of a package, like `^2 || ^3` if they are both compatible. We should be clear about documenting this so extension authors +can release extensions that are compatible with multiple major versions of JupyterLab. + ### Bots From 15ea284c153d03af9298e6b31977ac8222e67fa4 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 12:04:04 -0400 Subject: [PATCH 07/15] Spelling --- rfc/development-cycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index a509f26..39d15f6 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -62,7 +62,7 @@ Each increment has a corresponding "latest" branch for the greatest working vers Each PR should be tagged with one of three tags `semver:patch`, `semver:minor`, `semver:major` before it is merged. We could do this manually or by possibly giving a first guess [using type analysis](https://api-extractor.com/) or some commit message keywords. We should have a bot that blocks merging if one of these is not added. -If you have change that is *only* a backprt, and should not appear in master, then you can target that branch as the base of this merge. +If you have change that is *only* a backport, and should not appear in master, then you can target that branch as the base of this merge. ### PR Backports Once a PR is merged into master, backport PRs should be opened against all other open branches of the corresponding increment. From 4ee2a9d0afdadb8ef811875b66807c65b9c54ecd Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 12:06:29 -0400 Subject: [PATCH 08/15] Add note to use existing label bot --- rfc/development-cycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 39d15f6..fee847a 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -102,7 +102,7 @@ The "Bots" section is also a roadmap of what would need to be implemented to mov ### Pull request author **Semver Label**: Make sure pull request has appropriate semver label. -You can set it by either adding a commit with `semver:patch`, `semever:minor`, or `semver:major`, or setting the label in GitHub. +You can set it by either adding a commit with `semver:patch`, `semever:minor`, or `semver:major`, or setting the label in GitHub (optionally [using a bot](https://github.com/jupyterlab/jupyterlab/blob/master/CONTRIBUTING.md#tag-issues-with-labels)). **Changelog entry**: Add a new markdown or RST file in `docs/source/changes/new`. Use the current data and some rough title for the filename, so it is unique. If you want it to be under a subheader, make a subdirectory for that. Some common ones are `Bug fixes`, `For developers`, `User-facing changes`. If your change is small, just make it a single bullet in a list. From 8d3ac90b59722b1235285f88cf0a6499e427b4bf Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 12:13:11 -0400 Subject: [PATCH 09/15] remove old text on merge releases --- rfc/development-cycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index fee847a..6f0e9cf 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -153,7 +153,7 @@ can release extensions that are compatible with multiple major versions of Jupyt 2. Bump JS and push release 3. Create python release and test (optional) 4. Push python python release -5. Create new branches and create merge commits (on final release) +5. Create new branches (on final release) 7. Create PRs to other repos for new version (on final release) It takes three inputs, the branch you are releasing from, whether it's a pre release, and whether to force release without testing. If it is a pre-release, it should be one of `rc`, `beta`, `alpha`. From 6fb5da452a39553962350afee9a6465f51fdeac4 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 12:14:26 -0400 Subject: [PATCH 10/15] dont allow releaseing if no changelog entries --- rfc/development-cycle.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 6f0e9cf..49dd980 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -85,6 +85,8 @@ Each PR's milestone should reflect active milestone of the branch it targets. Each PR should add or edit a file in a directory full of files corresponding to unreleased changes, [like matplotlib does](https://matplotlib.org/devel/contributing.html#contributing-pull-requests). During a final release, these items are deleted from that file and compiled to a changelog file for that release. All of these files are included in the master changelog. +If there are no new changelog entries, we should not be able to make a release. + The changelog entries should be kept in chronological order, instead of semver ordering. ## Example From be0ab397a3a06eeebaeb723b29e9fe26632bd530 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Sat, 2 May 2020 13:46:27 -0400 Subject: [PATCH 11/15] Use branches to release --- rfc/development-cycle.md | 32 ++++++++++---------------------- 1 file changed, 10 insertions(+), 22 deletions(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 49dd980..912dc45 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -124,7 +124,9 @@ You can set it by either adding a commit with `semver:patch`, `semever:minor`, o ### Release Manager -To make a release go to {as yet unspecified page we will build} and you will see a list of all the open branches. Each branch will show you the number of commits since the last release on that branch. Also on each branch will be buttons for each of the releases you can make from that branch. Any branch which has a release ongoing (currently running) will show that. You can also delete any version branch from this UI where the last commit was a final version. +Find the pull request to release the version you want and merge it. This will trigger the release of the packages. There should be different pull requests for each in progress branch for the different types of next release, like `alpha`, `beta`, `rc`, and `final`. + +Once this release has been done, a list of open PRs will be posted to this PR, for any additional merges that need to happen in other repos. Also, you should delete the release branch if this was a final release and you don't want to do any more releases off of this branch. ### Extension Authors @@ -146,36 +148,22 @@ can release extensions that are compatible with multiple major versions of Jupyt **Base check**: Verify that the semver label corresponds to the increment of the branch of the base, if it isn't master. - **Update/create milestone**: Set the milestone to the next final release of the base branch. Update after every change of base branch and after every commit on the base branch. Create the milestone if it does not exist. -**Do release**: This should be an action with an API endpoint. It is the most complicated and involved action. It takes place in a number of stages: - -1. Input/pre-release check -2. Bump JS and push release -3. Create python release and test (optional) -4. Push python python release -5. Create new branches (on final release) -7. Create PRs to other repos for new version (on final release) - -It takes three inputs, the branch you are releasing from, whether it's a pre release, and whether to force release without testing. If it is a pre-release, it should be one of `rc`, `beta`, `alpha`. - -Before starting it checks to make sure the branch is version branch and that the pre release is valid. You can skip pre release phases, but you cannot go backwards. -This means if you just did a beta, you cannot do an rc, and if you just did an rc, you cannot do a beta or alpha. +**Changelog Release Check**: On each release PR, fail if there are no new changelog entries in the branch. -Next, it will checkout the branch in question and create a clean environment. Then it will run the appropriate `jlpm bumpversion` command (these will need to be updated) to create and publish the packages. +**Create Release PR**: After a new release is succesfull or when a new version branch is created, create other branches, in a fork of this repo, for each possible new release type. Run the command to bump all the JS versions properly for that release type, without actually publishing those versions. Also bump the Pyton version, without releaseing. Then open a PR to merge that branch into the original branch. We should also run the command to consolidate the documentation to a new release file. -Then it will publish all the JS packages `npm run publish:all`. +**Test Release PR**: On each release PR, run a special test for verifying the release works. This works by running a verdaccio server, publishing the npm packages to that server, and then installing the Python package with that proxy server. Then a number of integration tests are run, like opening a notebook and running some cells. It should persist these built packages as artifacts on Github actions. -Next it will run the end to end tests in a clean environment, if we are not doing a force release, (not the normal unit tests. This let's us publish even if these are failing). If these fail it will push what the JS version changes, but not the python one and exit. +**Do release**: Afte a release PR is merged, pull in the artifacts from the release PR and publish them to NPM and PyPi. Once that is successful it will push back tags for that release to the Github merge commit. -If they succeed, it will upload the wheel to python and push all tags and commits. -Now, if this was a final release, it has some more work to do! First, it will try to merge this release into another branch, as the "Branch Merging" logic dictates above. Then create new branches according to the "Branches" logic above. Push all of that. +**After final release, create new branches**: Once new tags have been pushed for a final release, create new branches based on the "Branches" logic above. -Then it will open PRs to the cookiecutter repos, if this was the latest release, to update them. +**After latest final release, update other repos**: After a final release that is the latest release, by semver, open a PR to each cookiecutter repos, and other extension repos, to upgrade them. Post a link to these on the release PR. -For any type of release, it will also open a PR against the conda forge repo, to release this version. It will create it on the same branch as the branch we made the release on in JupyterLab. +**After release, create conda packages**: After any release, create a PR against the conda forge repo to release that version. It will create it on the same branch as the branch we made the release on in JupyterLab, on some fork of that repo. Post a link to this on the release PR. ## Open questions From bc0d81d2586c81f60f5f234cb9f7874ba9e5c978 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Wed, 17 Jun 2020 14:51:01 -0400 Subject: [PATCH 12/15] Spelling --- rfc/development-cycle.md | 42 ++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 912dc45..938a6a2 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -14,7 +14,7 @@ Please give feedback on these first. You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) spec, having more to do with the relations between the code evolution between multiple versions. They assume we are already following SemVer. -**alpha, beta, rc**: Each release goes through some optional number of alpha, beta, and RC release, before the final. For some final release `{x}.{y}.{z}` it can be modeled with this state machine +**alpha, beta, rc**: Each release goes through some optional number of alpha, beta, and RC release, before the final. For some final release `{x}.{y}.{z}` it can be modeled with this state machine: 1. Start by releasing one of these: 1. `{x}.{y}.{z}a0` @@ -30,20 +30,20 @@ You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) sp * Minor: `{x}.{y}.0` is an ancestor of `{x}.{y+1}.0`. * Major: `{x}.0.0` is an ancestor of `{y+1}.0.0`. -**Single Active**: No commits will be queued up for a release until the previous increment was fully release +**Single Active**: No commits will be queued up for a release until the previous increment was fully released (this also falls out of the above assumption). * Patch: No commits towards `{x}.{y}.{z}` till `{x}.{y}.{z-1}` final is released. * Minor: No commits towards `{x}.{y}.0` till `{x}.{y-1}.0` final is released. * Major: No commits towards `{x}.0.0` till `{x-1}.0.0` final is released. -The last two mean you have to totally finish a release on one branch before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. However, you could have `1.2.0a0`, `1.1.1a0`, `1.2.0`, then `1.1.1`, because these would be on different branches, `1.x.0` and `1.1.x`. +The last two means you have to totally finish a release on one branch before you start on the next one. For example, it would be illegal to have releases in this order: `1.2.0a0`, `1.3.0a0`, `1.2.0`, then `1.3.0`. However, you could have `1.2.0a0`, `1.1.1a0`, `1.2.0`, then `1.1.1`, because these would be on different branches, `1.x.0` and `1.1.x`. **JavaScript versions In Sync** We are OK always keeping the JS version bumps in sync. Meaning that if we do a major release of the Python package we also do a major release of all JS versions. ## Strategy -Based on these assumption we can create a consistant branching strategy. +Based on these assumptions we can create a consistent branching strategy. ### Branches @@ -53,12 +53,12 @@ Each branch should be aligned to different releases: 2. Minor: `{x}.x.0` branches. After final release `{x}.{y}.0` create new patch `{x}.{y}.x` branch. 3. Major: `master` branch. After release `{x}.0.0` create new minor `{x}.x.0` branch and new patch `{x}.0.x` branch. -Each increment has a corresponding "latest" branch for the greatest working version. For example with two branches `2.x.0`, `1.x.0` the "latest" minor branch is `2.x.0`. The latest major branch is always `master`. +Each increment has a corresponding "latest" branch for the greatest working version. For example with two branches `2.x.0`, `1.x.0` the "latest" minor branch is `2.x.0`. The latest major branch is always `master`. *Note: We could instead have separate branches for each version, but this isn't necessarily if we are going by the **Single Active** assumption above.* -### PR Semver Tags +### PR SemVer Tags Each PR should be tagged with one of three tags `semver:patch`, `semver:minor`, `semver:major` before it is merged. We could do this manually or by possibly giving a first guess [using type analysis](https://api-extractor.com/) or some commit message keywords. We should have a bot that blocks merging if one of these is not added. @@ -87,7 +87,7 @@ from that file and compiled to a changelog file for that release. All of these f If there are no new changelog entries, we should not be able to make a release. -The changelog entries should be kept in chronological order, instead of semver ordering. +The changelog entries should be kept in chronological order, instead of SemVer ordering. ## Example @@ -103,24 +103,24 @@ The "Bots" section is also a roadmap of what would need to be implemented to mov ### Pull request author -**Semver Label**: Make sure pull request has appropriate semver label. +**SemVer Label**: Make sure pull request has appropriate SemVer label. You can set it by either adding a commit with `semver:patch`, `semever:minor`, or `semver:major`, or setting the label in GitHub (optionally [using a bot](https://github.com/jupyterlab/jupyterlab/blob/master/CONTRIBUTING.md#tag-issues-with-labels)). -**Changelog entry**: Add a new markdown or RST file in `docs/source/changes/new`. Use the current data and some rough title for the filename, so it is unique. If you want it to be under a subheader, make a subdirectory for that. Some common ones are `Bug fixes`, `For developers`, `User-facing changes`. If your change is small, just make it a single bullet in a list. +**Changelog entry**: Add a new markdown or RST file in `docs/source/changes/new`. Use the current data and some rough title for the filename, so it is unique. If you want it to be under a sub-header, make a subdirectory for that. Some common ones are `Bug fixes`, `For developers`, `User-facing changes`. If your change is small, just make it a single bullet in a list. **Milestone**: Don't touch this, it will be set automatically. -**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest semver release is 2.1.2, then use this label and set the base branch to `1.2.x`. +**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest SemVer release is 2.1.2, then use this label and set the base branch to `1.2.x`. ### Pull request merger -**Semver Label**: Verify the correct semver label is applied to the change. +**SemVer Label**: Verify the correct SemVer label is applied to the change. **Changelog entry**: Verify that any changes add or change an existing changelog entry. -**Review backports**: After you merge it, review all the backport PRs that were created and merge them if appropriate. Close any that are not relevent. Also for any backports the bot failed to make automatically, make them manually if they are necessary. +**Review backports**: After you merge it, review all the backport PRs that were created and merge them if appropriate. Close any that are not relevant. Also, for any backports the bot failed to make automatically, make them manually if they are necessary. ### Release Manager @@ -138,30 +138,30 @@ can release extensions that are compatible with multiple major versions of Jupyt ### Bots -**Semver label**: Whenever a PR has new commits, scan them for the semver label names in the messages, and if it finds any merge it with the existing, choosing the more breaking. Also look at special label like `feature:Bug` (patch) and `feature:Enhancement` (minor). +**SemVer label**: Whenever a PR has new commits, scan them for the SemVer label names in the messages, and if it finds any merge it with the existing, choosing the more breaking. Also look at special label like `feature:Bug` (patch) and `feature:Enhancement` (minor). -**Semver check**: Fail (and don't allow merging on this failure) on any PR that doesn't have one, and only one, of the `semver:patch`, `semver:minor`, `semver:major` labels. +**SemVer check**: Fail (and don't allow merging on this failure) on any PR that doesn't have one, and only one, of the `semver:patch`, `semver:minor`, `semver:major` labels. -**Create backports**: After a PR is merged into the `master` brnach, create backports for that release. It should target all other branches of the same increment according to the "PR Backports" logic above. +**Create backports**: After a PR is merged into the `master` branch, create backports for that release. It should target all other branches of the same increment according to the "PR Backports" logic above. -**Base check**: Verify that the semver label corresponds to the increment of the branch of the base, if it isn't master. +**Base check**: Verify that the SemVer label corresponds to the increment of the branch of the base, if it isn't master. **Update/create milestone**: Set the milestone to the next final release of the base branch. Update after every change of base branch and after every commit on the base branch. Create the milestone if it does not exist. **Changelog Release Check**: On each release PR, fail if there are no new changelog entries in the branch. -**Create Release PR**: After a new release is succesfull or when a new version branch is created, create other branches, in a fork of this repo, for each possible new release type. Run the command to bump all the JS versions properly for that release type, without actually publishing those versions. Also bump the Pyton version, without releaseing. Then open a PR to merge that branch into the original branch. We should also run the command to consolidate the documentation to a new release file. +**Create Release PR**: After a new release is successful or when a new version branch is created, create other branches, in a fork of this repo, for each possible new release type. Run the command to bump all the JS versions properly for that release type, without actually publishing those versions. Also bump the Python version, without releasing. Then open a PR to merge that branch into the original branch. We should also run the command to consolidate the documentation to a new release file. -**Test Release PR**: On each release PR, run a special test for verifying the release works. This works by running a verdaccio server, publishing the npm packages to that server, and then installing the Python package with that proxy server. Then a number of integration tests are run, like opening a notebook and running some cells. It should persist these built packages as artifacts on Github actions. +**Test Release PR**: On each release PR, run a special test for verifying the release works. This works by running a Verdaccio server, publishing the NPM packages to that server, and then installing the Python package with that proxy server. Then a number of integration tests are run, like opening a notebook and running some cells. It should persist these built packages as artifacts on GitHub actions. -**Do release**: Afte a release PR is merged, pull in the artifacts from the release PR and publish them to NPM and PyPi. Once that is successful it will push back tags for that release to the Github merge commit. +**Do release**: After a release PR is merged, pull in the artifacts from the release PR and publish them to NPM and PyPi. Once that is successful it will push back tags for that release to the GitHub merge commit. **After final release, create new branches**: Once new tags have been pushed for a final release, create new branches based on the "Branches" logic above. -**After latest final release, update other repos**: After a final release that is the latest release, by semver, open a PR to each cookiecutter repos, and other extension repos, to upgrade them. Post a link to these on the release PR. +**After latest final release, update other repos**: After a final release that is the latest release, by SemVer, open a PR to each cookiecutter repos, and other extension repos, to upgrade them. Post a link to these on the release PR. **After release, create conda packages**: After any release, create a PR against the conda forge repo to release that version. It will create it on the same branch as the branch we made the release on in JupyterLab, on some fork of that repo. Post a link to this on the release PR. @@ -172,4 +172,4 @@ can release extensions that are compatible with multiple major versions of Jupyt ## Further work: -**Changelog bot**: Bot that helps you auto generate changelog entries from git commits or PR descriptions. Comment `bot:generate-changelog` in the PR to create one from the github issue contents. It will replace/create a changelog file using the title of the PR and the issue number. +**Changelog bot**: Bot that helps you auto generate changelog entries from git commits or PR descriptions. Comment `bot:generate-changelog` in the PR to create one from the GitHub issue contents. It will replace/create a changelog file using the title of the PR and the issue number. From 3fa2a90a43dd01324bd3b0fd5600c594ca494479 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Wed, 17 Jun 2020 14:51:25 -0400 Subject: [PATCH 13/15] typo --- rfc/development-cycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 938a6a2..83a8676 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -55,7 +55,7 @@ Each branch should be aligned to different releases: Each increment has a corresponding "latest" branch for the greatest working version. For example with two branches `2.x.0`, `1.x.0` the "latest" minor branch is `2.x.0`. The latest major branch is always `master`. -*Note: We could instead have separate branches for each version, but this isn't necessarily if we are going by the **Single Active** assumption above.* +*Note: We could instead have separate branches for each version, but this isn't necessary if we are going by the **Single Active** assumption above.* ### PR SemVer Tags From 55bf0b34dcd26630e58574eef80237b60c26e79c Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Mon, 22 Jun 2020 11:58:33 -0400 Subject: [PATCH 14/15] Rephrase intro --- rfc/development-cycle.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 83a8676..590d5e2 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -7,9 +7,7 @@ This is meant to support our existing release cycles, not change them, but just ## Assumptions -I have found it helpful to try to first outline the assumptions of our release and development process. - -Please give feedback on these first. +We start with a list of assumptions/guarantees to constrain the possible space of solutions. You can consider these in addition to the [SemVer 2.0.0](https://semver.org/) spec, having more to do with the relations between the code evolution between multiple versions. They assume we are already following SemVer. From 8e2fbaeea4773929788c0688bc4871ba9583c056 Mon Sep 17 00:00:00 2001 From: Saul Shanabrook Date: Mon, 22 Jun 2020 12:02:10 -0400 Subject: [PATCH 15/15] Remove outdated reference to label --- rfc/development-cycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/development-cycle.md b/rfc/development-cycle.md index 590d5e2..84f6485 100644 --- a/rfc/development-cycle.md +++ b/rfc/development-cycle.md @@ -109,7 +109,7 @@ You can set it by either adding a commit with `semver:patch`, `semever:minor`, o **Milestone**: Don't touch this, it will be set automatically. -**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest SemVer release is 2.1.2, then use this label and set the base branch to `1.2.x`. +**Branch base**: Normally don't touch this. However, if this PR is not meant for the latest release, but instead only for a backport to an older release, set the branch base to correspond to the branch you want to merge it against. For example if you have a fix only for the next 1.2.x release, but the latest SemVer release is 2.1.2, then set the base branch to `1.2.x`. ### Pull request merger