Welcome to MSDN Blogs Sign in | Join | Help

Release Cadence

Sorry I've been away a while.  It's been almost 2 weeks since I've posted anything of much interest.  It's been crazy trying to get so many things finished up by the end of the year and I just haven't had time to think straight.  I've been trying to figure out what I was going to talk about next now that I've pretty much spilled the beans on everything we're doing for Orcas :)  I figure it's best to just pick something I'm passionate about.

I'm passionate about delivering value as early and as often as we can.  I wanted to share some thoughts with you and solicit some feedback.  Don't take anything I'm going to say here as official Microsoft policy or a statement of direction for DevDiv or anything of the sort.  Take it as the ramblings of someone who thinks about this stuff a lot.  Also, these comments are mostly focused on what I think we should do with Visual Studio.  For a variety of reasons the .NET Framework will have some different constraints.

Over the past several months you've seen a few initiatives kicked off to help improve transparency and value.  Among them are:

  • An increase in "release to web" features - the TFS Power Toys, ASP.NET Web Application Projects, Ajax, VS Tools for Office, etc.
  • A pilot program to start publishing QFEs - it has stalled a bit due to resource conflicts with SP1 but I expect it to get going again soon.
  • An initiative to start publishing specs for people to comment on early in the development cycle.
  • The introduction of CTPs and new ways of delivering them to make them even more accessible.
  • A VS SP with new features as opposed to only a rollup of bug fixes.
  • And more...

These are all good steps but they don't fall into a comprehensive plan for how we deliver value and when.  I've been thinking a lot about it lately and proposing a new model to people.  The new model I have in my head looks something like this.  It's a bit simplified to avoid this mail getting too long and don't confuse what I'm describing that's in my head with what we do today.

Major Releases - These are what you think of as VS releases today (VS2002, VS2003, VS2005, ...).  They are developed a fairly regular cadence with a target interval of something like 24 months.  They contain sweeping improvements and in many cases "Revolutionary" advancements (like .NET, WCF, WPF, Linq, etc).  They are the "big bang" and are designed to make quantum improvements in the lives of developers.

Minor Releases - Minor releases would be small releases that are a combination of bug fixes and features.  I think of them as an evolution of and a replacement for service packs.  I'm thinking we should target having them every 6 - 9 months.  They would be pure "evolution".  The goal of them is to take the current feature set and just make it better - fix dissatisfiers, address bugs, add complimentary features (like FolderDiff and Annotate that we released as Power Toys for TFS), etc.  Minor releases would have an extremely high compatibility bar.  The goal would be for you to have no reason not move forward - just pure goodness: no disruption.  I'm thinking they would be "free" downloads but would prereq the last major release (you've got to have some motivation to move forward and pay us money :))  Like service packs, minor releases would be tied to the servicing lifetime of the Major release they target.

Off cycle - These would be releases of varying size and scope that are released "off the train".  They could take the form of something unsupported like the Power Toys.  Or something "partially supported" like the TFS MSSCCI provider (I won't derail into a conversation about "levels of support" - that probably warrants another conversation).  Other things that fall in this bucket are off cycle releases like the Ajax tool kit, etc.  Off cycle releases provide a lower overhead opportunity for individual product groups to delvier value to leading edge technology adopters on a more frequent and/or more irregular basis without having to coordinate across all of VS.  The expectation would be that many/most off cycle releases would ultimately be rolled into a major or minor release but not all.  It would depend on the situation.

CTPs & Specs - Community Technology Previews and Spec Previews would continue to be a valuable way to preview what it coming in Major, Minor (and in some cases) off cycle releases. 

Hot Fixes - We would continue to pursue the effort we currently have underway of making all hot fixes available for browsing and download, enabling you to find available fixes as quickly as possible.

 

Well, that's the 10,000 foot view of what I'm thinking.  What do you think?  It doesn't come without costs.  Major releases would become somewhat smaller increments than they are today because some of the feature would have come out in preceding Minor releases.  There's a ton of logistical issues we'd have to address internally to reduce the cost of producing a release and likely, in the short term, there would be an overall cost in the additional release overhead that I'd hope we could reduce over time with practice and tooling.  This would mean an end to service packs as we know them today as pure bug fix delivery mechanisms.  Is that OK?

Again, please don't get me in trouble by going around and telling people "Brian said DevDiv is ...".  It's just me musing.  If everyone likes the ideas, they may influence where we go in the future.  If everyone hates them, they'll die on the vine :)

What do you think?

Brian

Published Thursday, December 14, 2006 12:02 PM by bharry

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Release Cadence

That's all very nice, but when will we get SP1 for VS2005?

Thursday, December 14, 2006 1:50 PM by kiwiblue

# re: Release Cadence

I think the one major thing to change would be to make VS a lot more split up into components that don't effect each other, have full support for isolated installation of different versions of components and integrate that with source control.

An example: The LINQ preview. Today, you install it, and then have a choice to have the new beta compiler or the old released compiler as the default for VS. But it is an all or nothing decision. If you want IDE integration, you have to use it for ALL projects. A better design would be that you install LINQ and by default NOTHING changes in VS. But PER project you get a new choice of compiler: The new LINQ enabled C# compiler. But it is all a per project setting and you KNOW that by installing the LINQ CTP nothing of your old stuff breaks.

My ideal scenario would be to have a dialog in VS that shows me new components available online for VS. So, I might see a new component "LINQ preview" there. I can select that component, and VS will download it and install it. By install, I think the design of VS should be such that I can be 100% that by installing it I ONLY get a new option for a compiler that I can select for projects. But I must be sure that the new compiler is installed side-by-side with the old version and doesn't "take over" any of my existing projects.

Ideally I would then also think that such "extra components" that are used within a project are tracked by the component, are added automatically to source control (for that project) and if someone else opens that project from TFS, all necessary build and design components that are used by that project are automatically pulled from TFS and installed. In a way I would want that ALL build and design components are versioned alongside the source code in TFS for each project.

All of that would probably mean to not use MSI for VS component installation but more some ClickOnce like tool that allows VS to make sure that installation of a new component is 100% additive to the existing VS installation.

I honestly believe this is the only way to handle Off Cylce and CTP releases in a reasonable way, i.e. the ability to use them for some projects but not for all.

So, my idea is that you can have a very large number of components installed. Installed means "available but not used by default for anything". Plus projects have very clear info in them which components (and which versions of those) are used and allow VS (or a build machine) to handle the dependency management for build/design tools.

Not sure this is very clear, but the main problem with the CTPs right nows seems to be that they tend to overwrite old released versions of components and don't allows easy, simple side-by-side management. VS seams to be where Windows was a couple of years ago, when you always had to fear that installing a new program would break other apps. Right now it is a bit like that with VS: I am very afraid to install CTPs/add-ons, because I can't be sure that they don't break my existing VS installation.

Thursday, December 14, 2006 3:12 PM by davidacoder

# re: Release Cadence

The problem with the status quo is that the major releases jump the competition (Eclipse) significantly, but the competition usually match features within 12 months leaving VS.Net lagging  for 12-24 months.

The way you describe regarding major releases with minor updates along the way is very similar to Apple's major and minor release strategy for MacOS and it's associated apps. IMHO Apple hit the nail on the head with their strategy.

Thursday, December 14, 2006 4:06 PM by rbirkby

# re: Release Cadence

I generally like the idea of having the major releases spread out a little longer with the minor releases providing expanded functionality.  It is generally difficult to get everybody on board that you should move up to the latest and greatest - so it would be nice to get new functionality on the same version.  

Thursday, December 14, 2006 4:10 PM by Scott Lee

# re: Release Cadence

kiwiblue: Since you asked nicely, here you go: http://msdn.microsoft.com/vstudio/support/vs2005sp1/default.aspx

In case you didn't see the news we RTM'd SP1 on the 14th so your timing was perfect. :-)

Brian Keller

Friday, December 15, 2006 1:07 AM by briankel

# re: Release Cadence

I like the idea of minor releases. You can take stuff that might have been offcycle and put into the minor releases too. The idea of a visual studio auto update site would also be nice.

Friday, December 15, 2006 4:09 AM by ahmed

# re: Release Cadence

Kiwi - see here :): http://blogs.msdn.com/bharry/archive/2006/12/15/visual-studio-sp1-is-released.aspx

David, What you propose is pretty radical and I'll need to think about it a bit.  I get what you are suggesting but I'm not sure I know how to do all of it.  Our current approach to the general problem of mixing and matching components and isolation from breakage in that kind of environment is to ship our CTPs in VPCs so that you can install them an use them with risk to your production environment.  A few comments on your sub points:

We are talking about a tool that would allow you to easily add your entire tool set to version control.  That's actually what we do internally for our projects and it makes sense to me for us to make that a lot easier for our customers.  It's not at the top of our priority list but it's on our minds.

There is also a novel effort going on in VS to seriously rethink the way one installs VS.  There's actually a prototype where you can install VS onto a USB hard drive and plug it in to any machine and use it.  It's designed to prove that you can just copy files around with no install what-so-ever and have it work.  I'd be interested to hear how important people think this kind of thing is.

Brian

Friday, December 15, 2006 6:42 AM by bharry

# re: Release Cadence

I think Minor Releases are a lot better then service pack, given all the problems you have with MSI and large service packs.  I don't mind if I have to uninstall the old version first and can't role back without uninstalling the new version and installing the old version by hand, if it lets you get "goodness" out to me quicker.

(I can even cope with having to reinstall all add-in to VS every 6 to 9 months if needed.)

Friday, December 15, 2006 6:46 AM by Ian Ringrose

# re: Release Cadence

I think having a major release every 2 - 3 years is fine. In these releases I would expect significant new functionality.  That said, I think it is a travesty that VS.NET 2003 was out with obvious issues and never really got a service pack until well after VS 2005 shipped!  DevDiv must do better about patching VS more often.  The teams I work with are running into continous crashes in large C/C++ projects.  I'm really hoping that VS 2005 SP1 will address a lot of these issues and I'm "somewhat" encouraged that this SP made it out almost within a year VS 2005 RTM.  

I'm also encouraged by TFS Power Toys (although I'm really hoping you rename these to Power Tools).  The Power Toys that were done before that for VS just weren't very useful.

As for minor releases, I'm not sure about this one since I do want the significant big bang releases and I want regular service packs.  Most development works I work with can only swallow tools changes every 2-3 years.  I'm not sure if a minor release would be viewed as a major tools change or not?  See in the past, we've been screwed by solution/project file format changes between what should have been a minor release (VS.NET 2003).  I guess it depends on the impact of the minor release. If it is a drop in replacement, no changes required to get access to say better productivity tools in the IDE then that would probably be fine.  One other issue, is that doing major, minor and regular service packs may spread even the mightly Microsoft too thin. If that is the case, I would forego the minor releases.  Besides you can always slip in minor new features in a service pack and most organizations wouldn't hesitate to roll out that service pack where they might hold up on a minor release.

Friday, December 15, 2006 11:42 PM by keith_hill

# re: Release Cadence

I like the suggested model.  It seems very obvious and natural.  The only improvement over your suggestion is to make hotfixes available via Microsoft Update so that they are pushed out more regularly instead of sitting waiting on a shelf somewhere waiting to be discovered and pulled down.   Minor releases could be available as optional downloads, again making discovery and installation much easier.

David's suggestion isn't really that radical or difficult, really.  The new project types, such as a C# 3.0 project, could be released in a seperate VS package.  They could be installed side-by-side with C# 2.0 projects allowing the same IDE installation to work with both production and pre-release code.  You're already doing this with the produdtion code and the pre-release tool support for the .NET Framework 3.0 components.

The only place this breaks down is when a new package requires an enhancement to the core IDE.

BTW, I like your new practice of making CTP's available in VPC's, too.  This makes it much easier to not only isolate it from my production tools, but also to make it MUCH easier to set up and test.  Many times by the time I had finally gotten around to installing the last CTP, a new one was released.  The new model is much better.

Saturday, December 16, 2006 7:18 PM by Erik Wynne Stepp

# re: Release Cadence

A couple of thoughts on the feedback so far.  It sounds like people are generally in favor of the minor release idea.  Keith stuggles with one of the things I struggle with.  To add a bit more detail to what I'm thinking...

In my mental model minor releases and service packs would merge and they wouldn't be two separate things.  Every "major" release would be followed by a series of "minor" releases - probably packaged as patches like SPs are today.  Until the following major release, the minor releases would be on a fairly regular cadence of 6 - 9 months apart and would consist of a combination of bug fixes, support for new configurations/technologies and new features.  After the subsequent major release the minor releases for the previous major release would switch to "on demand" and generally just include bug fixes.

So said another way, we'd continue to ship new features for the last major release in the market on regular intervals but only do bug fixes for previous versions (like SPs work today).

Part of my theory behind this is that if we deliver a minor release on the last major version every 6-9 months and major versions average 24 months apart then we'll get 2 to 3 minor releases in before the next major one.  This is a huge increase over what we do now and should provide plenty of opportunity to fix the most painful issues that slipped through in the initial release so that switching to "on demand, bug fix only" after 24 months should work pretty well.

The issue Keith struggles with is whether or not customers would view these "minor" releases like SPs or like major releases.  I agree that's a big question - and quite honestly a big part of what I'm asking you with this post.  How would you view it?  And would you be willing to update that often?

One of the tenents that I set forth for minor releases is that they are as close to 100% compatible as we can get.  I certainly wouldn't expect project file format changes :)  On the other hand, the more you change, the more risk you run of breaking something somewhere.

I also like Erik's feedback about looking at some kind of more push model.  We're nervous about doing this today.  The reason has to do with how we test hot fixes.  Generally we only do "unit testing"; we don't do system testing.  This is to keep the cost down.  As such it's helpful to give you more control over what you are getting because there's a very real possibility of regressions in other areas/scenarios.  Part of the plan for the hot fix site is to provide a forum for you to vote and comment on the fixes so that you can share issues, work arounds, etc.

I'm keeping an eye on a new effort by the exchange team.  Mary Jo Foley wrote about it here: http://blogs.zdnet.com/microsoft/?p=140

If this turns out to be popular and successful it might be something we look at and would get us closer to the "push" model.

Anyway, thanks for the thoughts.  I really appreciate all you have to say on the subject.

Brian

Monday, December 18, 2006 8:30 AM by bharry

# VSTS Links - 12/21/2006

Richard Hundhausen on Visual Studio 2005 and Vista. Neno Loje on Available Check-In policies for Team...

Thursday, December 21, 2006 8:26 AM by Team System News

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker