Here we document the various release processes and other boring topics.
All new releases first go through the dev version of the extension. This way we can get early feedback from testers on obvious issues without breaking the (much larger) stable user base.
https://chrome.google.com/webstore/developer/detail/okddffdblfhhnmhodogpojmfkjmhinfp
https://chrome.google.com/webstore/developer/detail/algkcnfjnajfhgimadimbjhmpaeohhln
New developer builds are created and signed automatically by internal Google tools from the latest git revisions in the tree. That means the actual creation of the CRX archive is not run by local developers (anymore) as the CWS will block unsigned archives.
Googlers use mpm to download the CRX files.
Locate the CRX from the mpm browser. Drill down into the app-dev and extension-dev packages. Find a version id like 1-146602e4_5ab126a6_44d22cda_e4a5aa8c_570775fd. It will be different for each package.
With those versions in hand, run something like:
$ cd ~ $ mpm fetch -v 1-40368fdb_e541d43a_d1d0bd16_daf53a44_69d74102 security/nassh/app-dev app $ cp app.mpm/versions/*/extension.crx ./app.crx $ mpm fetch -v 1-2d440ada_27f741e4_ef8b2b81_719b289e_79809584 security/nassh/extension-dev ext $ cp ext.mpm/versions/*/extension.crx ./ext.crx $ rm -rf app.mpm ext.mpm
Now you'll have the app.crx and ext.crx archives to upload to the CWS.
You'll need to be part of the chrome-secure-shell-publishers group in order to manage things via the CWS.
Visit the CWS dashboard to upload the new CRX archives:
https://chrome.google.com/webstore/developer/edit/okddffdblfhhnmhodogpojmfkjmhinfp
https://chrome.google.com/webstore/developer/edit/algkcnfjnajfhgimadimbjhmpaeohhln
We no longer announce dev releases since we switched to automated builds.
Since the dev release process is less formal now, the flow for preparing a stable release requires a bit more effort.
Now would be a good time to go through and do sub-releases of other projects. e.g. See if hterm or libdot have had any changes. If so, update their respective ChangeLog files and create a new git tag for each of them.
If you look at the ChangeLogs and git tag -l, it should be obvious how to do this. If you're still unsure, consult these examples:
Don‘t forget to push the tags once you’ve created them locally!
We don't currently use signed tags.
Update the ChangeLog.md file with any relevant details since the last release.
Add any significant changes to concat/release-highlights.txt, and prune any old entries in here (see the comments in the file for details).
See commit e992bb2c819188421b010a7c4fdc96cfae48db31 and tag nassh-0.9 as examples, but don't create a tag yet!
The version should remain unchanged in the manifest_*.json files as we'll update that after we create a git tag.
Once all the release files look OK, we wait for the internal builders to produce the signed CRX files which we upload again. Then we do a sanity check to make sure the release works in the dev channel.
If there's a problem, go through the steps above again (landing fixes and updating ChangeLogs) until the dev CRX is stable.
Now that we have a commit we want to actually promote to stable, it's time to create a git tag and push it to the server.
We don't currently use signed tags.
Now that we've tagged the release and pushed it out, the version should be updated in the manifest_*.json files to point to the next one.
See commit ddb21ccd39010f4c537da2a104f1a8869fe1ee6c as an example.
After some time, life will be great and everyone loves the new version. That means it's time to promote the dev version to stable. The process basically grabs the stable CRX already created at the same time as the dev CRX by our infrastructure.
There are only minimal differences between the dev & stable CRX‘s -- settings in the manifest.json like the version, name, and icon paths. That’s why we can use the dev CRX to validate before taking the stable CRX and uploading it directly to the CWS without explicitly testing it first.
Visit the mpm browser again, but this time look at the app-stable and extension-stable packages. Use the same mpm flow as the dev step above to pull out the stable CRX's.
Visit the CWS dashboard to upload the new CRX archives:
https://chrome.google.com/webstore/developer/edit/pnhechapfaindjhompbnflcldabbghjo
https://chrome.google.com/webstore/developer/edit/iodihamcpbpeioajjeobimgagajmlibd
Look for “Upload Dogfood Version”. This will post the update only for Googlers to get some last minute feedback before releasing to the world. If you want to control the release more, you can set the percentage field, but usually we leave it unset (i.e. 100%).
Send an e-mail to the internal chrome-hterm group announcing the new release. Here's an example posting:
https://groups.google.com/a/chromium.org/d/msg/chromium-hterm/_AcmwvdGFCc/Cne7Q8B3CQAJ
Visit the CWS dashboard to upload the new CRX file:
https://chrome.google.com/webstore/developer/edit/pnhechapfaindjhompbnflcldabbghjo
https://chrome.google.com/webstore/developer/edit/iodihamcpbpeioajjeobimgagajmlibd
This time use the “Upload Updated Package” option. Once that‘s done, use “Remove” on the dogfood version so the display doesn’t get confusing.
Send the same announcement as before but to the the public chromium-hterm group.
We don't currently have any. We strive to keep the master branch stable. You should too!
Once _locales/en/messages.json has updates that need translating:
//depot/google3/googleclient/chrome/extensions/samples/tc/hterm/.BUILD is up to date.i18n_messages.js for editing.../convert_json_messages.py < .../nassh/_locales/en/messages.json > i18n_messages.js.//depot/google3/googledata/transconsole/xtb/ChromeExtensions/*.xtb but you won't use them directly.hterm dir mentioned above): blaze build messages_filesetblaze-bin/googleclient/chrome/extensions/samples/tc/hterm/messages_fs/_locales/..../nassh/bin/import-translations.sh .../google3/blaze-bin/googleclient/chrome/extensions/samples/tc/hterm/messages_fs/_locales/See the TC page for more details.
We don't have one. Releases are made as changes roll in.