What version are we on now?
October 21, 2009 5:04 PM Subscribe
How do software authors determine the version numbers of the releases? I am writing software for a specific electronic device. I am not using version control on it yet. (Yeah, shame! Truth is, I am intimidated.)
I am working on this project alone. (Details: Front-end GUI in VB.NET back-end work done in a DLL in C++. The other part is embedded in the controller card using a PIC P24FJ256GB110.)
I expect that the software will go through some gyrations when the user figures out what he really wants. I will need to get versions for the GUI and the DLL and check for compatibility between them.
If you have suggestions about version control (for one) I'll take those too. I installed Subversion and TortoiseSVN, but I don't know how to use it effectively. I am confused as to when to do a commit. And don't even ask me about branches... I just don't get it.
I am working on this project alone. (Details: Front-end GUI in VB.NET back-end work done in a DLL in C++. The other part is embedded in the controller card using a PIC P24FJ256GB110.)
I expect that the software will go through some gyrations when the user figures out what he really wants. I will need to get versions for the GUI and the DLL and check for compatibility between them.
If you have suggestions about version control (for one) I'll take those too. I installed Subversion and TortoiseSVN, but I don't know how to use it effectively. I am confused as to when to do a commit. And don't even ask me about branches... I just don't get it.
When working on a project solo, I commit all the time. A little less often than I save to disc. On a larger team you might need to worry about when to commit to head, etc, but alone there's no such concerns.
I'm used to seeing a couple kinds of versions. At a minimum you will have the revision number from source control from which a given package was built, and also a user-readable number like 1.0: a major.minor version which reflects the specific version of the application in terms of expected features and bug fixes but doesn't always map neatly to source control revision. I also use a lot of version numbers like 1.0-001 where the 001 reflects packaging, often stuff not in source control, the result, for example, of a build format. It's this second number which you should probably use for tracking compatibility (and for future roadmap planning).
Don't worry about it. You have SVN on hand, you're going to use it soon, the revision numbers will be tracked automatically, and inevitably you'll have a 1.0 release. You can develop your own habits and use of branching etc as you go.
posted by doteatop at 5:25 PM on October 21, 2009
I'm used to seeing a couple kinds of versions. At a minimum you will have the revision number from source control from which a given package was built, and also a user-readable number like 1.0: a major.minor version which reflects the specific version of the application in terms of expected features and bug fixes but doesn't always map neatly to source control revision. I also use a lot of version numbers like 1.0-001 where the 001 reflects packaging, often stuff not in source control, the result, for example, of a build format. It's this second number which you should probably use for tracking compatibility (and for future roadmap planning).
Don't worry about it. You have SVN on hand, you're going to use it soon, the revision numbers will be tracked automatically, and inevitably you'll have a 1.0 release. You can develop your own habits and use of branching etc as you go.
posted by doteatop at 5:25 PM on October 21, 2009
There are all kinds of way to enumerate software versions. One pretty common method is to use major/minor version numbers (together with a build number, in many cases). Version 1.0 becomes version 1.1 (that's a minor version number difference) when some bug fixes get made. Version 1.1 becomes version 2.0 when a major functional change has been made. A 'full' version number might be something like 'version 2.1 build 7593'.
As for version control, there are lots of solutions. Subversion is among the most commonly used. The short answer about when to commit is 'when you're at a stopping point in feature development/bug fixing, and the committed code works as correctly as you can make it.' That is, don't check in code that doesn't compile, or is functionally incomplete. Obviously you may check in code that's buggy without knowing it, or because the (known) bugs are not high priority fixes.
posted by axiom at 5:27 PM on October 21, 2009
As for version control, there are lots of solutions. Subversion is among the most commonly used. The short answer about when to commit is 'when you're at a stopping point in feature development/bug fixing, and the committed code works as correctly as you can make it.' That is, don't check in code that doesn't compile, or is functionally incomplete. Obviously you may check in code that's buggy without knowing it, or because the (known) bugs are not high priority fixes.
posted by axiom at 5:27 PM on October 21, 2009
Subversion commits are not versions, they're just revisions. Normally you do a commit whenever you're done working or have made a lot of changes. Committing is the new saving. Actually Linus Torvalds, the author of the version control system git (among other things) advocates commuting very frequently, although with git it's a very, very quick process (and I don't know if there are revision numbers, like with SVN)
There's not really any need to worry about releasing new versions. If a lot of people use your product, and you want to add new features then you can bump up the version number when a lot of new features are added, and the minor number whenever compatibility changes.
For a DLL it's a good idea to make sure you bump up the version number whenever compatibility changes, so you don't end up with the wrong version of the DLL somewhere.
posted by delmoi at 5:28 PM on October 21, 2009 [1 favorite]
There's not really any need to worry about releasing new versions. If a lot of people use your product, and you want to add new features then you can bump up the version number when a lot of new features are added, and the minor number whenever compatibility changes.
For a DLL it's a good idea to make sure you bump up the version number whenever compatibility changes, so you don't end up with the wrong version of the DLL somewhere.
posted by delmoi at 5:28 PM on October 21, 2009 [1 favorite]
As for version control, there are lots of solutions. Subversion is among the most commonly used. The short answer about when to commit is 'when you're at a stopping point in feature development/bug fixing, and the committed code works as correctly as you can make it.'
If you're working a project yourself, just commit all the time, since it means you'll be able to go back if need to retrieve old code without worrying if it's still in the undo buffer. On older version control systems there's the theory of "breaking the build" where someone commits something that breaks the software and screws everyone else up. But if you're working by yourself, it's not a big deal.
With so-called "distributed" version control systems like Git, you can commit whenever you want, and share changes with whoever might need them.
posted by delmoi at 5:33 PM on October 21, 2009
If you're working a project yourself, just commit all the time, since it means you'll be able to go back if need to retrieve old code without worrying if it's still in the undo buffer. On older version control systems there's the theory of "breaking the build" where someone commits something that breaks the software and screws everyone else up. But if you're working by yourself, it's not a big deal.
With so-called "distributed" version control systems like Git, you can commit whenever you want, and share changes with whoever might need them.
posted by delmoi at 5:33 PM on October 21, 2009
Yeah, you commit all the time. I usually commit at the end of the day if I've done something significant. Try to make sure the code compiles and runs before committing.
In terms of version numbers, it's Major.Minor.Bugfix
For example, the first time you release with all the basic features, it will be 1.0
1.0.1 and 1.0.2 would be bugfix releases where you don't really add any new features but just fix up some problems. 1.1 and 1.2 would introduce new features. 2.0 would normally be a significant update in architecture or a big feature upgrade.
posted by demiurge at 5:46 PM on October 21, 2009
In terms of version numbers, it's Major.Minor.Bugfix
For example, the first time you release with all the basic features, it will be 1.0
1.0.1 and 1.0.2 would be bugfix releases where you don't really add any new features but just fix up some problems. 1.1 and 1.2 would introduce new features. 2.0 would normally be a significant update in architecture or a big feature upgrade.
posted by demiurge at 5:46 PM on October 21, 2009
Best answer: Others have pretty much said what I might - and are more informed on Subversion, etc. - but I'll add a few thoughts as a former retail software developer and a VP of Product Development in a publicly traded retail software publishing firm.
When I was doing this (about 15 years ago), the general rule was that if you are putting out an upgrade that simply has some bug fixes, the version number increments up by 0.1. That is, Version 1.0 becomes Version 1.1. These upgrades were usually released online or on a CD mailed to the end user as a normal course of supporting their product purchase.
When you have a new title release because of major functionality improvement (i.e., the next generation" of the product), then the pre-decimal number increments by 1 and the post-decimal number becomes zero. That is, Version 1.1 becomes Version 2.0.
If you are making a LOT of tiny incremental changes as you fix bugs (e.g., every few weeks), and making that version available online, then there may be a need for an extra digit that could be incremented. For example, Version 1.1.3 has a couple of bug fixes and a new build is released online, so the new build is incremented to 1.1.4. Some products even have finer granularity than this, of course.
It may make sense to have this fine a degree of granularity in version numbers if you're doing a lot of these little fixes and want to make them available relatively quickly. However, you may wish to slow down the release frenzy and the customer support challenges that can come from trying to maintain quality control and manage so many versions in the pipeline. So you may prefer not to have this fine a granularity in version releases. If your distribution mode is simply putting the latest file online for download, though, there may be little overhead (other than testing) involved in having new builds released so frequently.
One final thought: as was mentioned above, the Version numbers can very much be a marketing issue. End users can become incensed if they see an increment from v. 2.0 to 3.0 when the only thing that has happened was a few bugs were fixed. Similarly, if you've added a whole new area of functionality, you'll be short-selling the merits of the new version if you only increment from v. 1.0 to 1.1.
And an example of how marketing can be a pressure on these things: on one of our company's products, a software program on which I was the Project Director and Senior Technical Writer and which sold more than a million copies worldwide, our very first version was v. 2.0. Marketing made the decision to skip the v. 1.0 designation so as to make consumers think the title was already in its second generation (and therefore even better than it ostensibly was when it was first released).
As for technical aspects of how to commit or how to use specific version control software now in vogue, I'll defer to folks that know far more about that than I do, anymore.
posted by darkstar at 6:00 PM on October 21, 2009 [1 favorite]
When I was doing this (about 15 years ago), the general rule was that if you are putting out an upgrade that simply has some bug fixes, the version number increments up by 0.1. That is, Version 1.0 becomes Version 1.1. These upgrades were usually released online or on a CD mailed to the end user as a normal course of supporting their product purchase.
When you have a new title release because of major functionality improvement (i.e., the next generation" of the product), then the pre-decimal number increments by 1 and the post-decimal number becomes zero. That is, Version 1.1 becomes Version 2.0.
If you are making a LOT of tiny incremental changes as you fix bugs (e.g., every few weeks), and making that version available online, then there may be a need for an extra digit that could be incremented. For example, Version 1.1.3 has a couple of bug fixes and a new build is released online, so the new build is incremented to 1.1.4. Some products even have finer granularity than this, of course.
It may make sense to have this fine a degree of granularity in version numbers if you're doing a lot of these little fixes and want to make them available relatively quickly. However, you may wish to slow down the release frenzy and the customer support challenges that can come from trying to maintain quality control and manage so many versions in the pipeline. So you may prefer not to have this fine a granularity in version releases. If your distribution mode is simply putting the latest file online for download, though, there may be little overhead (other than testing) involved in having new builds released so frequently.
One final thought: as was mentioned above, the Version numbers can very much be a marketing issue. End users can become incensed if they see an increment from v. 2.0 to 3.0 when the only thing that has happened was a few bugs were fixed. Similarly, if you've added a whole new area of functionality, you'll be short-selling the merits of the new version if you only increment from v. 1.0 to 1.1.
And an example of how marketing can be a pressure on these things: on one of our company's products, a software program on which I was the Project Director and Senior Technical Writer and which sold more than a million copies worldwide, our very first version was v. 2.0. Marketing made the decision to skip the v. 1.0 designation so as to make consumers think the title was already in its second generation (and therefore even better than it ostensibly was when it was first released).
As for technical aspects of how to commit or how to use specific version control software now in vogue, I'll defer to folks that know far more about that than I do, anymore.
posted by darkstar at 6:00 PM on October 21, 2009 [1 favorite]
Let me just make a small clarification to the above: because we liked to slow down our release schedule for version quality control purposes, usually our bug fixes were released along with some minor feature upgrade. Hence, the increment from 1.0 to 1.1.
If all you're doing is making a few bugfixes, then the version increment would be more appropriately an increment in the third digit, such as v.1.1.0 to v.1.1.1.
posted by darkstar at 6:03 PM on October 21, 2009
If all you're doing is making a few bugfixes, then the version increment would be more appropriately an increment in the third digit, such as v.1.1.0 to v.1.1.1.
posted by darkstar at 6:03 PM on October 21, 2009
I recommend that you spend some time getting yourself comfortable with version control. Try reading a book like Pragmatic Version Control. If you have ever, or ever will accidentally delete a file, make a change that doesn't work and wish you had the old version back, you will recoup your investment in learning about version control.
You can commit as often as you want. Generally speaking, when it's just you working on the project, the more often you commit the better! That way, if you've discovered you have made a change that breaks everything, you can roll back to a previous version.
posted by mrgoldenbrown at 6:08 PM on October 21, 2009
You can commit as often as you want. Generally speaking, when it's just you working on the project, the more often you commit the better! That way, if you've discovered you have made a change that breaks everything, you can roll back to a previous version.
posted by mrgoldenbrown at 6:08 PM on October 21, 2009
Best answer: Here's how we do it on the project I'm on now:
x.y.z, where:
x == backwards-compatibility broken, architecture modification
y == noteworthy feature deprecation/replacement
z == bug fixes/minor improvements
But it really is arbitrary. If you care more about useful numbers than about marketing, simply define what you think each number should represent and stick to it.
posted by davejay at 6:09 PM on October 21, 2009
x.y.z, where:
x == backwards-compatibility broken, architecture modification
y == noteworthy feature deprecation/replacement
z == bug fixes/minor improvements
But it really is arbitrary. If you care more about useful numbers than about marketing, simply define what you think each number should represent and stick to it.
posted by davejay at 6:09 PM on October 21, 2009
Actually, I should correct that: that's the way we did it on my LAST project. On the current one, it's:
x.y, where:
x == major feature deprecation/replacement
z == minor feature deprecation/replacement, bug fixes, minor improvements
Like I said, arbitrary.
posted by davejay at 6:10 PM on October 21, 2009
x.y, where:
x == major feature deprecation/replacement
z == minor feature deprecation/replacement, bug fixes, minor improvements
Like I said, arbitrary.
posted by davejay at 6:10 PM on October 21, 2009
I feel like I should clarify, my comments about making sure the code compiles et cetera were (as delmoi suggests) more for multi-developer scenarios, where incomplete/non-functioning commits will break other devs' builds. Yes, if you're all by your lonesome, you can commit every 10 seconds if you see fit.
That said, even when I'm developing alone, I still tend to avoid committing partially-complete chunks of code. Part of that is force of habit (I also write meaningful commit log entries every time I commit, and this would get tedious if I committed as often as I save my buffers out), and part of it is just avoiding the added hassle of commiting when Ctrl + S (or whatever your shortcut) is usually sufficient.
posted by axiom at 6:40 PM on October 21, 2009
That said, even when I'm developing alone, I still tend to avoid committing partially-complete chunks of code. Part of that is force of habit (I also write meaningful commit log entries every time I commit, and this would get tedious if I committed as often as I save my buffers out), and part of it is just avoiding the added hassle of commiting when Ctrl + S (or whatever your shortcut) is usually sufficient.
posted by axiom at 6:40 PM on October 21, 2009
It's totally arbitrary. On my own current project, we have an W.X.Y.Z version number from legacy status, like so:
W roughly corresponds to the phase of the contract, for all intents and purposes; by definition all of the related projects will always have W match up at all times, even if the other values increment.
X means really major feature changes
Y used to be unused, now we're using it for "the database schema has changed such that you have to run some update scripts or rebuild it" (other related projects on the same contract have other uses for this position)
Z is for every time the customer actually gets a new production build, unless changes are so dramatic as to warrant a change X.
So, yeah, pretty arbitrary.
posted by Tomorrowful at 6:41 PM on October 21, 2009
W roughly corresponds to the phase of the contract, for all intents and purposes; by definition all of the related projects will always have W match up at all times, even if the other values increment.
X means really major feature changes
Y used to be unused, now we're using it for "the database schema has changed such that you have to run some update scripts or rebuild it" (other related projects on the same contract have other uses for this position)
Z is for every time the customer actually gets a new production build, unless changes are so dramatic as to warrant a change X.
So, yeah, pretty arbitrary.
posted by Tomorrowful at 6:41 PM on October 21, 2009
echoing that the version numbering is arbitrary, and mostly orthogonal to using source control.
I'd recommend using mercurial (or git if you have someone to ask questions to) for solo development. It requires zero setup, and easy in incorporate other people into development eventually.
posted by mezamashii at 7:22 PM on October 21, 2009
I'd recommend using mercurial (or git if you have someone to ask questions to) for solo development. It requires zero setup, and easy in incorporate other people into development eventually.
posted by mezamashii at 7:22 PM on October 21, 2009
Ditto to the "arbitrary" bit. For some interesting case studies (although most fall into the "not to do" category), check out this article. In the end it's certainly up to you, though.
posted by hatta at 7:28 PM on October 21, 2009
posted by hatta at 7:28 PM on October 21, 2009
Best answer: There's various ways of counting, and various reasons for marketing to change the numbering. Ubuntu uses a sortable date format: 9.04 is April 2009, for example. The system that makes the most sense I've seen is to tag every build with a revision number, in addition to whatever marketing numbers attached, so if someone reports a problem with version 5.03, they can check and see that it's 5.03r2454. It's possible to look up the source code revision number during build and define a constant for this purpose.
On using revision control effectively, there's two approaches: "commit early, commit often" and "commit sensible patch sets." The former is good for a project under heavy initial development, where you don't need substantial code review because you're just following the design you set forth. You could take the approach of committing every time you build successfully, and perhaps work it into your IDE to do so automatically. The main value here is being able to freely remove code. Every programmer, faced with a bug or build failure, follows a progression:
1. Novice programmers change and rechange the only copy, perhaps stumbling upon a correct change eventually, possibly changing a lot more than necessary in the process. They sometimes forget what the original looked like.
2. Experienced programmers "comment out", or #ifdef 0 the code, to embed the old version in the code as a comment so they don't lose the old version. They sometimes forget to remove the old code.
3. Excellent programmers change and rechange the working copy, eventually stumbling upon a correct change. They then do a commit and compare the two versions, and see how much of the diff can be rolled back.
The "sensible patch set" is better for mature projects, where the system is integrated and (hopefully) is passing automated tests. In this case you also want to pay close attention to the log messages, so you know what the hell you did a month from now. What do you do when you discover some bug that didn't use to happen (a regression), and you're not sure how long it's been there. A day? A month? If you imagine the revision history as a linear search space, you can binary search for the commit that introduced the bug, giving you some fairly good insight about what broke and maybe why. In this case, having related changes grouped together makes it possible to tease out which subsystem is responsible, and a sensible changelog (perhaps containing a bug report number) will help you judge whether the code in question meets its intended purpose, or if there's a forgotton component that needs to be adjusted in light of the change.
Branching is easy. Branching is what happens when you copy the source code and give it to a friend without revision control: there's now two source code repos accumulating change. It's merging, the process of taking those two change sets and unifying them, that's damn hairy. But even if you don't ever merge, it's still handy to have branches around representing the state of the code in the field. Especially with embedded software that you can't bring open an about dialog on.
Or you can use branching to represent the state of the code at a particular iteration. If the customer decides they like it better the old way after seeing the change implemented, it's easy to recall the exact source code you used.
posted by pwnguin at 7:58 PM on October 21, 2009
On using revision control effectively, there's two approaches: "commit early, commit often" and "commit sensible patch sets." The former is good for a project under heavy initial development, where you don't need substantial code review because you're just following the design you set forth. You could take the approach of committing every time you build successfully, and perhaps work it into your IDE to do so automatically. The main value here is being able to freely remove code. Every programmer, faced with a bug or build failure, follows a progression:
1. Novice programmers change and rechange the only copy, perhaps stumbling upon a correct change eventually, possibly changing a lot more than necessary in the process. They sometimes forget what the original looked like.
2. Experienced programmers "comment out", or #ifdef 0 the code, to embed the old version in the code as a comment so they don't lose the old version. They sometimes forget to remove the old code.
3. Excellent programmers change and rechange the working copy, eventually stumbling upon a correct change. They then do a commit and compare the two versions, and see how much of the diff can be rolled back.
The "sensible patch set" is better for mature projects, where the system is integrated and (hopefully) is passing automated tests. In this case you also want to pay close attention to the log messages, so you know what the hell you did a month from now. What do you do when you discover some bug that didn't use to happen (a regression), and you're not sure how long it's been there. A day? A month? If you imagine the revision history as a linear search space, you can binary search for the commit that introduced the bug, giving you some fairly good insight about what broke and maybe why. In this case, having related changes grouped together makes it possible to tease out which subsystem is responsible, and a sensible changelog (perhaps containing a bug report number) will help you judge whether the code in question meets its intended purpose, or if there's a forgotton component that needs to be adjusted in light of the change.
Branching is easy. Branching is what happens when you copy the source code and give it to a friend without revision control: there's now two source code repos accumulating change. It's merging, the process of taking those two change sets and unifying them, that's damn hairy. But even if you don't ever merge, it's still handy to have branches around representing the state of the code in the field. Especially with embedded software that you can't bring open an about dialog on.
Or you can use branching to represent the state of the code at a particular iteration. If the customer decides they like it better the old way after seeing the change implemented, it's easy to recall the exact source code you used.
posted by pwnguin at 7:58 PM on October 21, 2009
Oh yea, and only keep your working copy on your developer box, move the SVN repo itself off to a server, preferably one backed up regularly. You don't want a hard drive failure to end it all!
posted by pwnguin at 8:02 PM on October 21, 2009
posted by pwnguin at 8:02 PM on October 21, 2009
Nthing Major.Minor scheme, with build number appended.
The most memorable build numbering scheme I have seen is a 5 digit numbering scheme, starting with 10101 (on January first of the first year of the project), progressing to 10131 before rolling on to 10201, etc. Year 2 of project starts with 20101. God help you if you have a ten year project that outlives this scheme.
posted by crazycanuck at 9:00 PM on October 21, 2009
The most memorable build numbering scheme I have seen is a 5 digit numbering scheme, starting with 10101 (on January first of the first year of the project), progressing to 10131 before rolling on to 10201, etc. Year 2 of project starts with 20101. God help you if you have a ten year project that outlives this scheme.
posted by crazycanuck at 9:00 PM on October 21, 2009
Yeah, you commit all the time.
I usually commit at the end of the day
You and I have very different definitions of "all the time".
I generally commit whenever I have finished an atomic change; i.e., anything that I'm reasonably sure won't break the build. On a typical day I commit 5-10 times.
posted by dmd at 4:30 AM on October 22, 2009
I usually commit at the end of the day
You and I have very different definitions of "all the time".
I generally commit whenever I have finished an atomic change; i.e., anything that I'm reasonably sure won't break the build. On a typical day I commit 5-10 times.
posted by dmd at 4:30 AM on October 22, 2009
Response by poster: Thanks to all those who answered and to those that will answer later.
I am marking this "resolved" for the sake of bookkeeping but if anyone has anything to add, I will continue to monitor this topic as I like hearing the opinion of others.
I haven't marked an answer as "Best" because there are a number of answers that deserve the prize and all the answers are valuable.
posted by Drasher at 5:56 AM on October 22, 2009
I am marking this "resolved" for the sake of bookkeeping but if anyone has anything to add, I will continue to monitor this topic as I like hearing the opinion of others.
I haven't marked an answer as "Best" because there are a number of answers that deserve the prize and all the answers are valuable.
posted by Drasher at 5:56 AM on October 22, 2009
Obviously it's up to you and the points are made up, but you can mark multiple best answers. I don't know why I care; it's not like there's a high scores page.
posted by pwnguin at 11:18 AM on October 22, 2009
posted by pwnguin at 11:18 AM on October 22, 2009
I haven't marked an answer as "Best" because there are a number of answers that deserve the prize and all the answers are valuable.
You can mark as many answers best as you like.
posted by delmoi at 3:32 PM on October 23, 2009
You can mark as many answers best as you like.
posted by delmoi at 3:32 PM on October 23, 2009
This thread is closed to new comments.
Taste in revision control systems is a matter of taste. :) Although, certain control systems lend themselves better for small projects/large projects/small amount of developers/large amount of developers/developer locations, etc.
posted by seppyk at 5:08 PM on October 21, 2009