I have been working with SVN for the better part of around two years, and let me say, it is wonderful! When I first started to learn about version control, I tried to learn with THE standard, CVS. Well, a new player had made its way into the hearts of many developers, and Dan turned me onto it. What was it? It was Subversion. I won’t go into many of the details that made CVS different from SVN, but let me say that it allowed me to understand version control much better than I did with CVS.
If you are familiar with what a tag and what a branch is, you can skip the next couple of paragraphs. If not, read on for my explanation of what they are.
A tag is basically a snapshot of your code at a specific point in place. You don’t make any updates to a tag, you really only use it as reference. Why would you want to do something like this? Well, mostly it is for historical reasons. Whenever you release a new version of your code, you want to tag it so that you can always check out that version w/o having to remember the version number. In SVN a tag is basically just a label for a specific version of the repository, but labeling things is important.
Branches on the other hand are a bit more involved. The standard way of explaining tags is saying that it is parallel development of your code. What exactly does this mean though? Well, you can imagine that you want to release your code at some point in the future (if not, then reread this sentence until it is a true statement). You have features X, Y and Z that are being developed and you want version 1.0 to contain these features. Well, what happens if there is feature Q that is slated to be in 2.0, but you want to start developing it now? Well, what is normally done is that you can make a branch. Usually, new development is done in the trunk, so you would branch off the 1.0 code. At this point, you will now have two developments of your code. You will have your 1.0 branch to contain X, Y, and Z, and you will have the trunk (2.0) to contain Q, X, Y, and Z. You do all development in your trunk (i.e. 2.0), and anything that you want to release into 1.0, you merge from the trunk, into the 1.0 branch.
When you begin the development of your application, tags and branches will not be necessary. Every part of development will belong in the trunk and will most likely stay there until you have some initial release of the code. From that initial release will all of this complexity start to make sense. Believe me, it took me the better part of 6 months to finally understand the whole need for tags and branches beyond the standard examples given to you from Alice and Bob.
Ok, got the idea of tags and branches? Good!
In MyEPICS, we are just now getting ready to upload the code onto SourceForge. One of the topics that came up (or I brought up) was how to mange the version numbers of the code. I want the actual version number to mean something. When developing this idea, I had borrowed quite a bit from PHP. They have X.Y.Z, where X=Major, Y=Minor and Z=Release. I would think that MyEPICS can borrow from this idea to also have a X.Y[.Z] where Z is optional. X is the major release. The decision to bump up the major release would be done through decisions of what features will be implemented. As of right now, I cannot see anything that is slated would have a major number increase (mainly because of the differences between 1.0 and 2.0, which were pretty vast).
A minor release can contain such things as the addition of one or many modules and any features that aren’t too intense of a change.
As I see it, all bug fixes that are released will go into a “Release” release. I think it would be good to call it a bug release.
As this gets more set in stone I will keep all of this updated.