Branches

We'll operate on a two-branch system: one for active development ("master") and one for releasing stable builds ("release"). Except in rare circumstances, new check-ins will happen first on master. We'll occasionally merge master into release when we think it's in a fairly stable state. An example of a time at which this should happen is at the end of our sprint, when all the sprint features are complete and checked in. We can also cherry-pick bug-fix commits from the master branch into the release branch if they fix particularly high-priority bugs. We shouldn't do this for all bug-fix commits; just those that we consider to be ship-stoppers, for whatever definition of "ship" is currently in play. That is, if we're getting close to a major release, then we'll pick up bug-fix commits for moderately severe bugs, but if we're not near a major release then we'll only pick up bug-fix commits for high-severity bugs.

Tags

We'll use tags to indicate commits on the release branch that indicate particular releases. For example, we should tag a commit with sprint-N once the Nth sprint is complete, master has been merged into release, and release has been committed to the "playground-dev" Perforce sandbox. We should also tag commits for major Photoshop releases with the Photoshop version number, e.g., ps-16.0, as well as for their development waypoints, e.g. ps-16.0-RC.

Perforce synchronization

The release branch is the only one that we'll ever commit to any Photoshop Perforce repo. And, in particular, we'll only commit the release branch to the "playground-dev" sandbox. This will give the Photoshop developers who use this workspace for their daily work the first "opportunity" to experiment with what we think should be stable JavaScript code. They may find a high-severity bug, in which case we'll update our release branch and commit again to Perforce. If they do not, they will at some point propagate the JavaScript sources from the "playground-dev" sandbox to the "playground" staging sandbox. And, some time later, the staging sandbox and its JavaScript files will be propagated to the "main" sandbox.

Playground Adapter and Plugin

For now, we'll just use a single-branch strategy for playground-adapter. We'll version the playground-adapter bower package to correspond with the internal version of the plugin, and we'll specify a particular playround-adapter version number in the bower.json file in playground-design.

To set the version of playground-adapter, we can use bower:

$ npm version 0.1.56
or simply
$ npm version minor
then
$ git push origin --tags master

This will 1) increment the version number in the bower.json file in playground-adapter; 2) create a commit tag named v0.1.56; and 3) push that tag to the remote repository.

At some point, we should also write code to confirm at runtime that the playground plugin version is semver compatible with the playground-adapter plugin.

npm shrinkwrap

As part of the release process, if the adapter version has changed, we must update npm-shrinkwrap to include the correct version.

Ensure modules are loaded correctly with the steady state
$ npm install
Force the install of the correct adapter version
$ npm i --save adobe-photoshop/spaces-adapter.git#v1.2.0
Re-shrinkwrap
$ npm shrinkwrap
$ git commit -am "Updated shrinkwrap with new spaces-adapter version"

This process can also be used to update other external dependencies that are known to work correctly.