A couple of aspects of this have come up on the post where I announced the TFS 15 RC1 and I thought it was worth a more explicit call out. First some context.
We have 2 release “types” for TFS – major releases (TFS 2013, TFS 2015, TFS 15, etc.) and Updates (TFS 2015 Update 1, TFS 2015 Update 2, …). We think about them very differently and have different promises around them. While nothing I say here should be taken too much as an absolute, they are the principles we try to operate by.
Updates are intended to be “no-brainers”. We work very hard in Updates not to break anything or change anything that might disrupt your workflow or make the upgrade difficult. We don’t, generally, change our pre-request, deprecate any features, etc. in Updates. Our goal is that you should feel safe upgrading your TFS server and continuing to work as you always have – it’s just better.
Major releases are where we introduce larger, more disruptive changes. One of the examples that came up on the RC1 thread was a change in supported versions of SQL Server. TFS 2015 and all of it’s updates supported SQL 2012 and SQL 2014. TFS 15 will no longer support SQL 2012 and will add support for SQL 2016. That change can be more or less disruptive, depending on the organization you are in. Some organizations have very elaborate “enterprise certification” processes for SQL Server versions. Some do not.
I assume it’s obvious that we can’t support all versions of all dependencies forever. Every version of a dependency increases the test matrix, requires us to write more special case code to accommodate different behaviors in various versions, etc. So we have to draw the line somewhere so we can focus an increase fraction on our effort delivering you improvements you want rather than supporting lots of old versions. Major releases are when we make changes. Our practice for each dependency varies. We tend to be much more restrictive for things that are server side dependencies (like SQL Server). We tend to be much less restrictive for things that get installed on desktops (Office, Visual Studio, Eclipse, etc.) or that have additional dependencies themselves that have ripple effects.
To help people prepare for the changes, we’ve produced a couple of documents explaining the requirements for TFS 15. The first excerpts some of the key differences from TFS 2015. The second tries to capture all of the requirements. I’ve already seen a couple of things missing and asked that they get added but it’s pretty comprehensive.
I alluded to deprecating features in major releases but didn’t really discuss that here. I have some homework to do to pull together a comprehensive roadmap for how the existing feature set will change and I plan to write a post just on that.
Hopefully this helps you prepare for the upcoming TFS release.