.NETCF: The mini Y2K

Kolkata Trip 2009

I am sure most people haven’t yet forgotten the Y2K problem. This year our team faced a mini Y2K, but don’t worry we anticipated it and all is well.

If you head over to NETCF Wikipedia page you’d notice the NETCF versions look as follows


A sample version number is


This represents .NETCF version 3.5 build on the 283rd day of 2007. I guess by now you can guess the problem. We use a single digit to represent the year. By that nomenclature, the version of the build churned out today would be 3.5.0001.0 which is lower than the one generated the year before and would fail to install.

These numbers are automatically generated by scripts on the server that churns out daily builds. The numbering system was invented a long time ago in early 2000 and no one bothered to fix it. We anticipated that it’s going to fail as we move into the new decade and have updated it to now have 2 digits for the year (and yes we know it will break again in the future, but hopefully that’s too far out to care right now).

Happy new Year.

Comments (3)

  1. Prabir says:

    I had figured out the same problem even before it happened. For my source code i use the following format:


    Its a bit tricky though.

    For example v1.10009.11226.11157, would be equivalent to

    Major: 1,

    Minor: 100,

    Year: 09,

    Month: 12 (December),

    Day: 26th,

    Hour: 11 (24hr clock),

    Minutes: 57

    Best way is to add 1 before starting anynew numbers. One bad thing about this is even the Minor already starts with 1.1 rather than 1.0

    the Minor i put it for 3 digits so i can go to 1.3, 1.45 or stuffs like that which would be easier for consumers to understand.

  2. Prabir a much better solution is to use yymmdd because that way you can sort the folder by name and it’ll still sort by the version

  3. Prabir says:

    yymmdd is a better solution.

    i even tried tat long time back,but we are allowed to have only max of 5 digits as version numbers in .net