ilyakooo0/urbit
1
0
Fork 0
mirror of https://github.com/ilyakooo0/urbit.git synced 2024-08-15 13:40:31 +03:00
Code Issues Packages Projects Releases Wiki Activity

meta: update CONTRIBUTING, MAINTAINERS

Browse Source 
Adjusts these documents to reflect our new branching/release procedure.
This commit is contained in:
Jared Tobin 2020-03-16 11:32:55 +04:00
parent c0cc4a1db8
commit d1f3530a5b
No known key found for this signature in database
GPG Key ID: 0E4647D58F8A69E4
2 changed files with 42 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
CONTRIBUTING.md
View File

@ -158,9 +158,8 @@ commit that updates the source.
## Releases
We typically create releases by cherry picking appropriate commits from
`master` and tagging the result, so any given commit in `master` may not
actually be present in the latest release.
We typically create releases by tagging appropriate commits on `master`, so any
given commit in `master` may not actually be present in the latest release.
We perform updates by pushing releases over-the-air to `~zod` approximately
once per week, so any contribution that can be deployed OTA will usually find

122
MAINTAINERS.md
View File

@ -45,87 +45,40 @@ to use. My .git/config contains the following, for example:
so that I can type e.g. `git mu origin/foo 1337`.
### Apply the changes to this era's release branch
### Prepare a release commit
For now, the release branch corresponds to the `vx.y` part of the most recent
Vere release (i.e., `urbit vx.y.z`). At the time of writing, we're on v0.10
(and I'll use this branch as a running example):
If the branch doesn't yet exist, just create it via:
```
git checkout -b v0.10 master
```
If you can get away with merging master to v0.10 without pulling in any
superfluous or non-OTA-able commits, feel free to do that. Otherwise, you'll
want to cherry pick the commits like so:
```
git cherry-pick -x TARGET_COMMITS
```
Use the `-x` flag to `git-cherry-pick`, because this will indicate in the
commit message where the things originally came from.
A useful technique is to cherry-pick merge commits on master directly. Take
following commit, for example:
```
commit 769996d09
Merge: 171fcbd26 8428f0ab1
Author: Jared Tobin <jared@tlon.io>
Date: Sun Feb 2 19:11:04 2020 +0400
Merge branch 'liam-fitzgerald/langserver-doc-autocomplete' (#2204)
* liam-fitzgerald/langserver-doc-autocomplete:
language-server: magic-spoon hover, autocomplete
language-server: build ford prelude
language-server: dynamically compute subject
language-server: revive rune/symbol completion
language-server: add completion JSON parsers
Signed-off-by: Jared Tobin <jared@tlon.io>
```
rather than cherry-picking the individual commits, one could just use the
following while on the release branch:
```
git cherry-pick -x -m 1 769996d09
```
you can check the man page for `git-cherry-pick(1)` for details here.
Create Landscape or alternative pill builds, if or as appropriate (i.e., if
anything in Landscape changed -- don't trust any compiled JS/CSS that's
included in the commit).
You should create Landscape or alternative pill builds, if or as appropriate
(i.e., if anything in Landscape changed -- don't trust any compiled JS/CSS
that's included in the commit), and commit these in a release commit.
You should always create a solid pill, in particular, as it's convenient for
tooling to be able to boot directly from a given release. If you're making a
Vere release, just play it safe and update all the pills.
tooling to be able to boot directly from a given release.
If you're making a Vere release, just play it safe and update all the pills.
### Tag the resulting commit
What you should do here depends on the type of release being made.
First, for Arvo releases:
First, for Urbit OS releases:
If it's a very trivial hotfix that you know isn't going to break
anything, tag it as `arvo.yyyy.mm.dd`. Use an annotated tag, i.e.
anything, tag it as `urbit-os-vx.y.z`. Here 'x' refers to the product version
(e.g. OS1, OS2..), 'y' to the continuity era in that version, and 'z' to an
OTA patch counter. So for a hotfix version, you'll just want to increment 'z'.
Use an annotated tag, i.e.
```
git tag -a arvo.yyyy.mm.dd
git tag -a urbit-os-vx.y.z
```
The tag format should look something like this:
```
arvo.yyyy.mm.dd
urbit-os-vx.y.z
This release contains Arvo changes that will be pushed to the live
network as an over-the-air update.
This release will be pushed to the network as an over-the-air update.
Release notes:
@ -154,23 +107,25 @@ If the commit descriptions are too poor to easily do this, then again, yell at
your fellow contributors to make them better in the future.
If it's *not* a trivial hotfix, you should probably make any number of release
candidate tags (e.g. `arvo.yyyy.mm.dd.rc1`, `arvo.yyyy.mm.dd.rc2`, ..), test
candidate tags (e.g. `urbit-os-vx.y.z.rc1`, `urbit-os-vx.y.z.rc2`, ..), test
them, and after you confirm one of them is good, tag the release as
`arvo.yyyy.mm.dd`.
`urbit-os-vx.y.z`.
For Vere releases:
Tag the release as `vx.y.z`. The tag format should look something
like this:
Tag the release as `urbit-vx.y.z`. The tag format should look something like
this:
```
urbit vx.y.z
urbit-vx.y.z
This release contains Vere changes, so users should update their
binaries.
Release binaries:
This is not a breaching release, so users should not create new
piers.
(linux64)
https://bootstrap.urbit.org/urbit-vx.y.z-linux64.tgz
(macOS)
https://bootstrap.urbit.org/urbit-vx.y.z-darwin.tgz
Release notes:
@ -183,23 +138,26 @@ Contributions:
The same schpeel re: release candidates applies here.
Do not include implicit Arvo changes in Vere releases. This used to be done,
historically, but shouldn't be any longer. If there are Arvo and Vere changes
to be released, make two releases.
Do not include implicit Urbit OS changes in Vere releases. This used to be
done, historically, but shouldn't be any longer. If there are Urbit OS and
Vere changes to be released, make two releases.
### Deploy the update
For Arvo updates, this means copying the files into ~zod's %base desk. The
(**Note**: the following steps are automated by some other Tlon-internal
tooling. Just ask `~nidsut-tomdun` for details.)
For Urbit OS updates, this means copying the files into ~zod's %base desk. The
changes will be synced to /~zod/kids and then propagated through other galaxies
and stars to the rest of the network.
For consistency, I download the release tarball and then rsync the files in:
For consistency, I create a release tarball and then rsync the files in.
```
$ wget https://github.com/urbit/urbit/archive/arvo.yyyy.mm.dd.tar.gz
$ tar xzf arvo.yyyy.mm.dd.tar.gz
$ wget https://github.com/urbit/urbit/archive/urbit-os-vx.y.z.tar.gz
$ tar xzf urbit-os-vx.y.z.tar.gz
$ herb zod -p hood -d "+hood/mount /=base="
$ rsync -zr --delete urbit-arvo.yyyy.mm.dd/pkg/arvo/ zod/base
$ rsync -zr --delete urbit-urbit-os-vx.y.z/pkg/arvo/ zod/base
$ herb zod -p hood -d "+hood/commit %base"
```
@ -209,7 +167,7 @@ the new binary, and restarting the pier with it.
### Announce the update
Post an announcement to urbit-dev. The tag annotation, basically, is fine here
-- I usually add the %base hash (for Arvo releases) and the release binary URLs
(for Vere releases). Check the urbit-dev archives for examples of these
-- I usually add the %base hash (for Urbit OS releases) and the release binary
URLs (for Vere releases). Check the urbit-dev archives for examples of these
announcements.