Welcome to tankete.com Sign in | Join | Help

José Lema

Inside the Community Server development team

Shared Posts


Badges



  • www.flickr.com
    This is a Flickr badge showing public photos from tankete. Make your own badge here.
What's in a Version Number?

Up until last year, we (Telligent) were using a version numbering scheme for Community Server that appeared would last indefinitely. Based on a post by ScottGu, our format was [major].[minor].[date].[buildnumber], where date was in "ymmdd" format and buildnumber was the number assigned to us by our continuous integration software (CruiseControl.NET). All seemed logical and the world was good. Now that 2007 has rolled around, we come to realize that the date portion (today = 70111) causes problems and won't build successfully. I guess we never realized it, but each portion of the version number is required to be and Int16, as stated here:

All components of the version must be integers greater than or equal to 0. Metadata restricts the major, minor, build, and revision components for an assembly to a maximum value of UInt16.MaxValue - 1. If a component exceeds this value, a compilation error occurs.

Oops! Surprise

So now we're in uncharted waters. What to do? Are we the only ones (in addition to all of devdiv over at Microsoft)? A couple of ideas have been tossed around, none seem as nice as the previous, but maybe one is always fondest of his/her first version numbering scheme. :P

So, any ideas? Dare I say it's what's holding up Community Server 3.0 Beta 1? Wink

Share this post: StumbleUpon | email it! | bookmark it! | digg it! | reddit!
Posted: Thursday, January 11, 2007 4:08 PM by Jose
Filed under: ,

Comments

Colin Bowern said:

You could just drop the date notion all together.  I've found it really provides no value in the long term.  We focus on major, minor version, and the build number as an indicator of where we are at.  Once we deem a build suitable for release the build number is marked as RTM, SPx, etc... Then we increment major and/or minor version numbers and continue on the next release.

# January 11, 2007 8:30 PM

Jose said:

Colin: I was going to mention in the post that date is really important to us, but decided against it since I didn't want to bias the replies (even though I probably just did :). Since the build number doesn't make it back into our source control system (Subversion) it's nearly impossible (okay, not that bad) for us to figure out *when* the build occurred. With some form of date it makes things a lot easier.

# January 11, 2007 8:51 PM

David Voss said:

ZOMG! It's a conspiracy by Microsoft to impede the release of CS 3.0 Beta 1!!

# January 11, 2007 9:03 PM

Chris Hammond said:

No TFS for Telligent???

# January 11, 2007 9:20 PM

Robert McLaws said:

http://blogs.msdn.com/buckh/archive/2007/01/06/how-to-deal-with-the-y2k7-problem-file-versions-and-assemblyinfotask.aspx

# January 11, 2007 9:22 PM

jayson knight said:

Easy...do an unsafe cast to a UInt32 ;-).

If this is what's holding up CS3B2 I'm firebombing the Dallas office!

# January 11, 2007 10:42 PM

Jose said:

David: Based on Robert's link below, Microsoft has already answered. (Thanks Robert)

# January 11, 2007 10:56 PM

Jose said:

Chris: At this time we've decided TFS is really too much for us.

# January 11, 2007 10:57 PM

Jose said:

Jayson: Easy there tiger! Then again, most of us product folk are remote...bombs away :P

...sorry Kevin :)

# January 11, 2007 10:58 PM

Marc said:

How about a month number for the CS 3 release?  01,02,03,04 or ... (gulp) higher?

# January 11, 2007 11:20 PM

Jose said:

Marc: As we've stated previously, "Calypso is planned for release in the first quarter of 2007". We're doing our best to stick to that statement. :)

# January 11, 2007 11:39 PM

Community Server News said:

Up until last year, we ( Telligent ) were using a version numbering scheme for Community Server that

# January 12, 2007 12:20 AM

David Voss said:

So they put it off for about 5 years?

xMMDD where x = 1 which represents 2006.  Not very intuitive but if that's what works then hey, why not.

I kinda like the one suggestion posted on the MSBuild Team Blog where someone suggests yyddd.

# January 12, 2007 4:37 PM

Jose said:

David: I'm not sure that they "put it off for 5 years". I think they just decided to go with "yyyy mod 5". Remember, "y" is just "yyyy mod 10". The likelihood of collisions/misinterpretations seems small. I actually like this solution best. Furthermore, the "math" happens once at the beginning of the year while the yyddd requires math everytime you do a new build. And it also requires math when you want to go the other direction.

# January 12, 2007 4:53 PM

Marc J said:

I forget where I saw it, but someone suggested the date format become <year><day number i.e. 1 - 365>

so 20th Jan 2007 would be 7020, 5th February becomes 7036

In theory it should provide valid dates up to some time in 2064 :)

# January 17, 2007 4:38 AM

Jose said:

Marc: Yeah, that was one of the suggestions here last week as well. While some liked the idea, others felt it involved too much math or required an external program to help figure things out.

# January 17, 2007 11:12 AM

John said:

Why not start at 1/1/2000 as 1, 1/2/2000 as 2 and continue. Restart your numbering in a lot of years. Simple and yet will work and a Excel spreadsheet or a simple web service query could return the result of 3 being 1/3/2000, etc.

# March 27, 2007 12:16 PM

Jose said:

John: The problem with that approach, IMHO, is that it's too hard to figure out what today is. Since today is March 27, 2007, it takes me a while to figure out that it's 6 (yrs) * 365 (days) + 2 (leap year) + 31 (jan07) + 28 (feb07) + 27 = ??? Also going the other way ain't too easy. Quick, what date is 21212? :)

I know we could use a tool to figure it out, but we ultimately went with ymmdd where y is year mod 5. So today is 20327 and 21212 is 12/12/02 OR 12/12/07. We felt that ambiguity isn't too bad since it's five years apart.

# March 27, 2007 12:46 PM
New Comments to this post are disabled