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 two active branches of development accessible to everyone on GitHub.

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. Pre-release packages may be (periodically) published after automatic nightly validation.
• 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, a new release is created, and stable packages are published. Note: master HEAD may not be stable while we validate, please always sync to the latest label

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
• Builds the sample apps that are part of the repo.
• Note: This is mostly only build step, so it may break some apps.
• Note: ARM tests are not run.

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.
• Publishes WinObjC pre-release packages on a manual basis.
• 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

Twice a month, we have a Shiproom where (among other things), we do the following:

• Decide what code makes it into the our next release. This is an accumulation of the code in develop and potientially a few cherry-picked changes. This code is merged into master
• 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 and publish it to nuget.org
• Note: Currently we release once a month, but we may change that in the future depending on needs.

Which release should I use?

• For a stable build, use the last stable NuGet packages or sync to the commit tag from master that matches the desired stable release
• For contributions, or to stay cutting edge, use the pre-release packages and the develop branch.

Branches and Codeflow diagram