Release Process

WinOBJC Branches and Release Process

The WinOBJC team has been publishing regular releases over the last few months. The goal of this page is to clarify the internal process we have when we publish a release. This page also clarifies the different branches we have, and the quality gates that are in place on these branches. This process has undergone improvements over the last few months and will likely be tuned as we learn more.

Branches

We have three active branches of development. Two of these branches are on Github and accessible to everyone. The third is an internal development branch which is hosted on VSO.

develop branch (Github)

• This is the new active development branch for part of the WinOBJC Microsoft team.
• The code in this branch is minimally tested.
• This is also the default branch for the project (all pull-requests go here).

master branch (Github)

• This is our release/stable branch.
• Code is merged from develop to master on a regular cadence (explained later in this page).
• Once code is merged to master, we perform extended validation.
• Once validation is complete, the branch is tagged and a new release is created.
  Note: master HEAD may not be stable while we validate, please always sync to the latest label

develop branch (Internal)

• This is similar to the Github develop branch, but used only internally by part of the WinOBJC team and partner teams.
• Code from this branch is merged on a regular basis with entire history.

Quality gates

We have multiple quality gates on different branches. Our builds and tests are hosted internally on VSO, with commit triggers.

CI Build on develop branch

• This happens before a pull request is merged.
• Performs full build of the SDK package on X86 and ARM.
• Runs unit tests for x86 Debug and Release
• Extracts SDK, builds the sample apps that are part of the SDK.
• Note: This is mostly only build step, so it may break some apps.
• Note: Functional tests are not run, nor are ARM tests.

Nightly build on develop branch

• Performed every week day.
• Performs all the steps in CI build
• Builds several OSS sample apps (we are constantly adding more apps to the mix).
• Builds some real world apps.
• Performs launch tests on the apps that were built on ARM and x86.
• Performs unit tests and functional tests on ARM and x86.
• Performs additional validation (api analysis, which is where the annotations come into play).
• Publishes WinOBJC symbols to symbol server if you ever need to debug your app.
• Note: The launch tests don't test the apps, they just verify that the app can be installed and launched.

CI build on master branch

• Performed on commit
• Performs same list of steps as Nightly build on develop branch

Extended validation

• On special occasions, we perform extended validation.
• This includes manually installing and using some of the test apps that we produced and checking them for regressions.
• We do this during the weekly release and when we are making breaking changes (ex: the CoreFoundation change).

Release Process

• Every Tuesday, we have a Shiproom where (among other things), we pick the last change from the internal develop branch we want to merge.
• The changes are merged to Github develop branch and the accumulated changes are merged to master. This is the code for our next release.
• Master CI build has to pass all gates as described earlier.
• Extended validation should pass.
• If there are regressions, we cherry-pick changes and test again.
• When all gates pass, we tag the branch, and create a new release.
• Note: Currently we release once a week, but we may change that in the future depending on needs.

Which branch should I use?

• For a stable build, use the last tag from master to sync to, or use the last published set of binaries.
• For contributions, or to stay cutting edge, use the develop branch.

Branches and Codeflow diagram