Today we released the release candidate for Team Foundation Server 2018 Update 1.  Here are the important links:

• TFS 2018.1 RC1 Release notes
• TFS 2018.1 RC1 Web installer
• TFS 2018.1 RC1 ISO image
• TFS 2018.1 RC1 Express edition Web installer
• TFS 2018.2 RC1 Express edition ISO image

If you look at the release notes, you’ll notice they are a lot shorter than in previous Update 1s.  I want to spend a little time explaining what’s going on. Several years ago, for TFS, we adopted a cadence of a major release, followed by a couple of significant feature releases, followed by one or two releases which contained mostly bug fixes.  The major releases were typically ~18 months apart and the minor releases varied from 3-5 months apart.  We made some mistakes along the way but, overall, the cadence has been working reasonably well.

However, over the past year or so, our major release cadence has firmed up to be consistently 12 months apart – TFS 2017 shipped in Nov 2016, TFS 2018 shipped in Nov 2017 and we anticipate TFS 2019 will ship in Nov 2018.  This aligns well with our Connect event and provides a predictable schedule for us all to plan around.  However, this has also created some problems for us.  With Update 1 shipping in the spring and Update 2 shipping in the summer, Update 3 has started to conflict with our efforts in the fall to ship the subsequent major release.  This has caused us to have two concurrent on-prem releases in the fall – TFS V.current Update 3 and TFS v.next RTM.  We’ve found that this creates a level of stress and fog on the team that it isn’t working well for us.  So, this year, we’ve decided to make some changes to our approach.

The basic model remains the same – a major release with 3 intervening minor releases. However, the content of Update 1 will change from being a significant feature release to being mostly a bug fix release.  This enables us to shorten the intervals and reduce the overlap in the fall.  So rather than the TFS 2017 schedule:

• TFS 2017 RTM (November 2016) – A major release
• TFS 2017.1 (March 2017) – A significant feature update
• TFS 2017.2 (July 2017) – A significant feature update
• TFS 2017.3 (November 2017) – Mostly bug fixes

We’re expecting the TFS 2018 schedule to look more like:

• TFS 2018 RTM (November 2017) – A major release
• TFS 2018.1 (February 2018) – Mostly bug fixes
• TFS 2018.2 (May 2018) – A significant feature update
• TFS 2018.3 (August 2018) – Mostly bug fixes

Said another way, the bulk of the new features in TFS 2018 updates will come out in May rather than half in March and half in July.  To be fair, Update 1 won’t be *entirely* bug fixes.  There will be a few carefully selected new features that don’t have significant effort/schedule impact yet we believe are important to get out quickly. A good example in TFS 2018.1 is our support for GVFS caching to enable distributed teams to get better performance when working with large repositories.

Another way to understand this change is to think about it mechanically.  In TFS 2017, Update 1 and Update 2 were branched from master, meaning they contained all the sprint work committed in the intervening time.  Update 3 was branched from Update 2 so any changes for Update 3 were either directly made in the Update 3 branch or hand ported to the Update 3 branch from master.  This gives much more control over how much churn goes into the release.  In TFS 2018, Update 1 will branch from the RTM release branch and then, as before, Update 2 will branch from master. Update 3 will branch from Update 2.

Why are we changing this? First, this allows us to reduce the overlap between Update 3 and the next major release.  Second, preparing an on-premises release for any version which has a lot of churn is expensive.  On-prem releases involve much more regression and config matrix testing than our cloud releases.  For example, we have to test upgrades from many previous versions of TFS, many OS versions, several SQL server versions, etc.  The time spent doing all of that extra testing is less time spent working on improvements.  We believe that the aggregate impact here will be good for customers.  There will be 2 feature releases per year rather than 3 but they will be more evenly spaced (one every 6 months – major, then minor) and the aggregate amount of value will be increased due to less time spent in release validation.

These changes only affect our on-premises TFS product.  Our Azure-based VSTS service will continue to deploy from master every sprint (every 3 weeks). We’re still talking about exactly how this will affect our support strategy and are open to your input.  Over the past couple of years we’ve adopted a support strategy that accommodates two classes of customers:

1. Those who always want to be on the latest version and are willing to install every Update.
2. Those who want to pick a version to stay on for a year or more.

Both classes of customers need a good support story so that they can contact customer support and get help if they have problems. To enable these two different ways of managing updates, our policy has been that we provide long term support for every major release and for the “latest update” of each major release.  Customers who want to pick a version and stay on it should pick a major release and we will offer support and patches, as necessary, for the major release for the lifetime of the product.   Customers who want to aggressively update can install any Update they want and, if they need to get a patch, they will be asked to move to the latest Update for the major version they are on as part of getting the patch.

With the change I’m describing here, I fear, no matter how many assurances I give and no matter how pure my intent is, customers will perceive the .1 release as higher quality and more desirable than the RTM release.  And, at some level, I have to agree with them.  It is, after all, just RTM plus some bug fixes (and a few small, non-disruptive, features).  So, we’re considering the option to just embrace that. This would mean that for TFS 2018 going forward we would change our support model to provide long term support for the .1 release rather than the RTM release. In a sense, Update 1 *is* a patch for RTM and hence is on the servicing train for RTM.  The guidance to customers who want to stay on the most stable release possible with no changes, would be to either install the .1 or .3 Updates of any major release family. I’m open to thoughts/discussion on this.

Long post, I know.  Sorry.  I wanted to try to clearly explain what we are doing and why.  As always, we are open to your feedback.  At this point, we are committed to this cadence for the TFS 2018 product cycle but, as with everything, we will watch, listen and learn.  If this doesn’t work for people, we can either come up with a 3rd option or go back to what we were doing before with TFS 2019.  All options are on the table, but I think people are going to like this better.  We’ll see.

Brian