Mixedrealitytoolkit-unity: HoloToolkit-Unity 2017 release plans

[NeerajW]

Hello,

To make the release cadence more predictable and defined, we will mark a release of the code base in the first week of every month.

1. This gives us set timelines to plan our apps and when to move forward.
2. Makes it easier to keep track of what changes are going into every release.
3. You can update to latest more often rather than one big unity package which changed a lot.
4. Folks should also avoid breaking changes as much as possible unless there is huge value in doing so.

Thank you for all the awesome work and feedback!

[StephenHodgson]

@NeerajW, I think another good way to plan releases is with each Unity Editor update that makes big updates to the HoloLens platform, so we can stay fairly current as well.

[davidkline-ms]

I would like to suggest marking any breaking change pull requests using the newly added BREAKING CHANGE label.
This will allow reviewers to easily spot breaking changes.

Thanks@

[StephenHodgson]

Also having a separate branch just for releases would be good as well.

That will make VS build integration easier because builds only get triggered from pull requests that are native to the repository.

Team Services is being fitted with a trigger enabling developers to build GitHub pull requests automatically. Once the build is done, it will be reported via a comment in the pull request. "For security, we only build pull requests when both the source and target are within the same repo. We don't build pull requests from a forked repo," Microsoft said.

[NeerajW]

We should only create branches if we intend to maintain them. We currently don't merge fixes back and forth between branches so I have not found a reason yet. What do you think?

[StephenHodgson]

Good thing we only have one branch 😆

I think the Release Branch would only get pushed to trigger builds. No reason to pull from it.

@NeerajW, I would like to make sure the sharing services are updated before we make our first 2017 release.

[thebanjomatic]

To clarify because the title is a little ambiguous, are we talking releases of "HoloToolkit-Unity" this year, or are we talking specifically about new release policies starting with the "Unity 2017" release in a few months?

[thebanjomatic]

Monthly releases sounds OK, but that feels a bit slow to me. Infrequent releases means more changes are going into a given release which increases volatility and makes it harder to update when breaking changes do happen. Additionally, when you are waiting for that one bug fix, its kind of a pain to have to wait an entire month.

I have a couple thoughts on this:

1. There could be a branch for each release.
2. A best effort would be made to support the current release with bug fixes patched back from master.
3. Anyone who is holding onto an older release due to breaking changes can submit PR's for fixes targeting older releases, though upgrading may be preferable.
4. Patch releases would be made on the stable branch more frequently (weekly? daily? per change?)
5. Features and larger changes would continue to target master only, and follow the monthly release schedule.

[StephenHodgson]

Should we close https://github.com/Microsoft/HoloToolkit-Unity/issues/217 in favor of this issue?

It addresses everything we were talking about minus the releases on the Asset Store.

[StephenHodgson]

This info is now detailed on the main readme page