'The Device Bits in December CTP are older than November CTP' - How and Why does this happen ?

  • Article

I recently responded to a customer's question with a note saying that the device bits in the December CTP are older than the November CTP. I am sure the next logical question people would have in mind would be - how and why would that happen. I'll make an attempt at explaining why even a newer CTP could have some bits which are older than the previous CTP. Before I get into the detail, take a look at this blog by the release team which explains how our build process works.

So based on that we have the Main Build and multiple VBLs under that. A set of teams in the division check code into Labs assigned to them, example my team usuallys work in VBL22. We build each lab daily and then usually once a week or so, these changes are moved to the Main Lab. Once it passes the release criteria, that code from Main is then Reverse Integrated into the rest of the labs to get all labs in sync. And this cycle continue. 

The Dec CTP (looking at the help About) indicated that it from lab23 which is not the lab where my team checks code in directly. Also I noticed that the build number for this release is 041115 (Interpret YY,MM,DD). Which means that while this build has Lab23 bit which will be the most recent for the VS Team System , the bit from the Lab22 (my team's lab) could be considerably older depending on when Lab22 integrated to Main and then from Main to Lab23. Contrast that with the November CTP - it showed a build main.041202. So that should explain the How this happened.

Now to the Why part. Why does something like this happen ?. This Dec CTP release is focused on VS Team System. Once that team identifies a build in it's lab it takes then a few days to get the right set of fixes. During this phase we usually will not merge other labs so that this lab continues to be stable and in a known state. This means that team can deliver a stable build to our customers and can provide a good experience with the features they want to showcase in that build and it make the preview a lot more useful. The downside is that the other lab by virtue of the integration cycles will have older bits and this is exactly what happened in the Dec CTP.

So my suggestion to our device development community

- To try the latest feature set of VS Team Systems, sure use, the Dec CTP. If you are evaluating other features, most teams have team or individual blogs where they publish up to date known issues or build related information.

- For the latest feature in Managed Device development, continue to use the Nov CTP and the patch I put a few hours ago.

- And if you are doing Native Device development, Beta 1 release would be the best option so far. Nov CTP has a bug preventing Native Device Project from showing up and at this point and a patch for that is unlikely.

Couple of other suggestions.

When logging suggestions and defects from the Product Feedback Center, do mention the Build Number from Help About as it will help us get to the issue more quickly.

and

When installing these CTPs, I recommend a clean image of the machine. While uninstalling is getting better, a few older bits could stay behind making identification of some issues much harder for the team.

Our team would love to hear about your experiences with our tools so please feel free to use this blog, the product feedback center or the VS2005 newsgroups to send your thoughts / comments / suggestions our way. The microsoft.private.whidbey.smartdevices and microsoft.private.whidbey.smartdevices.cplusplus are the 2 most relevant newsgroups for device development for VS 2005 and you can continue to use the Microsoft public newsgroups for disucssion of VS 2003, NETCF 1.0 and eVC 4.0.

Thanks

Amit Chopra