Skip to content
This repository has been archived by the owner on Feb 22, 2018. It is now read-only.

Branches and Versions

Jump to bottom
sethladd edited this page Mar 25, 2013 · 4 revisions

At any given time, the pub team is in one of two modes:

  1. Normal mode
  2. Code freeze

Code freeze only occurs starting shortly before and continuing until shortly after a major release that will give pub.dartlang.org a user spike. It gives us a chance to make sure any changes to the site have been more heavily user-tested before a wider audience hits them. Whenever possible, though, we prefer to be in normal mode.

Git branches

master

The master branch is the bleeding edge for the site. Pull requests are merged into master. Any development occurring outside of master should happen in a branch that will eventually end up merged into master.

stable

The stable branch only exists during code freeze. Its existence determines whether or not a code freeze is active. When it exists, commits from master will be cherry-picked into it as needed. Once code freeze is lifted, the branch will be removed.

Feature branches

Feature branches can be freely created. All new work happens in feature branches which are then merged into master after code review. Feature branches may be long or short-lived.

AppEngine versions

The main rule here is you must not update the current version. If the current version on AppEngine is 123, then you cannot directly upload to 123. Doing so would mean you can't rollback to the previous version.

Numbered versions

The current AppEngine version (i.e. the one that pub.dartlang.org resolves to) will always be a monotonically increasing number. Every time we want to push a new live version of the site, we:

  1. Upload from master (or stable if in code freeze) to the next integer version number.
  2. Go to App Engine Console to determine the current version.
  3. From the command line: appcfg.py --oauth2 update -V NEXT_VERSION_NUMBER app
  4. Test.
  5. Make it the current version.
  6. Clean up any unneeded old versions. Keep around at least the previous one, and maybe a couple more if they've been revving frequently. Basically, if you think there's a chance we may want to revert the site to it, keep it around.

preview

This always corresponds to the latest code on master, even during a code freeze. It should always be safe to upload from master to the preview version on AppEngine (though it isn't required to do so on every commit to master).

staging

Just like preview. The only difference is that this hits the staging data.

Clone this wiki locally