Every day, we cope with software versioning.
We often hear sentences like: “Hey, have you seen the new Firebug 1.3.3?”, “Have you installed Ubuntu 8.10?”, “When will Windows 7 be released?”, “Is Gmail still in Beta?” or “Check my new web 2.0 site!”
Personally, and it seems that a lot of people agree about this, I like the Ubuntu versioning pattern: the major version indicates the year of releasing, and the minor one the year’s month when it was released.
If we talk about web applications, I prefer putting the revision number of the published revision in our source control in some hidden place, so if the application is hosted in different servers is easy to know what version of the software is our server running. (Note: check the downsides: if it’s a very public project, you are making cracker’s life easier)
It’s a reality that there aren’t any standards for software versioning and naming, and frequently development teams and marketing folks use different names for the same version of a product. As always, life will be easier if we had some standards in place.
But the way, we have some de facto conventions, and we should use them. If we use the popular X.Y.Z versioning format, a change in X implies massive architecture changes, and a change in Y means that there exists compatibility with other versions with same X.
If you are using .NET Framework, you should know that you can generate your assemblies version automatically based on the time of compilation. Check the article about
AssemblyVersionAttribute from the MSDN:
When specifying a version, you have to at least specify major. If you specify major and minor, you can specify an asterisk (*) for build. This will cause build to be equal to the number of days since January 1, 2000 local time, and for revision to be equal to the number of seconds since midnight local time, divided by 2.
If you specify major, minor, and build, you can specify an asterisk for revision. This will cause revision to be equal to the number of seconds since midnight local time, divided by 2.
This article came to my mind when I read about the new PHP release, PHP 5.3. The previous was only some context for my rant:
What were PHP people thinking about when they decided changing only the minor version number with a new version with backward-compatibility issues?
If you are going to feel the pain, maybe this IBM post series can ease you: What’s new in PHP V5.3.
PS: They’ve introduced
goto in the language too. I won’t say anything about it. Use it at your own risk.