{"id":12095,"date":"2016-08-09T11:13:57","date_gmt":"2016-08-09T16:13:57","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/bharry\/?p=12095"},"modified":"2019-02-16T22:46:13","modified_gmt":"2019-02-16T22:46:13","slug":"pre-reqs-for-team-foundation-server-15","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/bharry\/pre-reqs-for-team-foundation-server-15\/","title":{"rendered":"Pre-reqs for Team Foundation Server 15"},"content":{"rendered":"

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. \u00a0First some context.\nWe 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, …). \u00a0We think about them very differently and have different promises around them. \u00a0While nothing I say here should be taken too much as an absolute, they are the principles we try to operate by.\nUpdates are intended to be “no-brainers”. \u00a0We work very hard in Updates not to break anything or change anything that might disrupt your workflow or make the upgrade difficult. \u00a0We don’t, generally, change our pre-request, deprecate any features, etc. in Updates. \u00a0Our goal is that you should feel safe upgrading your TFS server and continuing to work as you always have – it’s just better.\nMajor releases are where we introduce larger, more disruptive changes. \u00a0One of the examples that came up on the RC1 thread was a change in supported versions of SQL Server. \u00a0TFS 2015 and all of it’s updates supported SQL 2012 and SQL 2014. \u00a0TFS 15 will no longer support SQL 2012 and will add support for SQL 2016. \u00a0That change can be more or less disruptive, depending on the organization you are in. \u00a0Some organizations have very elaborate “enterprise certification” processes for SQL Server versions. \u00a0Some do not.\nI assume it’s obvious that we can’t support all versions of all dependencies forever. \u00a0Every version of a dependency increases the test matrix, requires us to write more special case code to accommodate different behaviors in various versions, etc. \u00a0So 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. \u00a0Major releases are when we make changes. \u00a0Our practice for each dependency varies. \u00a0We tend to be much more restrictive for things that are server side dependencies (like SQL Server). \u00a0We 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.\nTo help people prepare for the changes, we’ve produced a couple of documents explaining the requirements for TFS 15. \u00a0The first excerpts some of the key differences from TFS 2015. \u00a0The second tries to capture all of the requirements. \u00a0I’ve already seen a couple of things missing and asked that they get added but it’s pretty comprehensive.<\/p>\n