7

I'm facing a problem to create a version control outline for several already existing software parts for my company. Until now no one - expect for the developers - knows that there are different versions, which is the reason for the outline. In fact, I'm supposed to set up the future version control and communicate all this with our management...

So, the question is how to create such a outline. Are there principles to follow to make software versioning easier or even a good program to map all versions and there compatibility?

And are there generally good approaches to control software versions?

Improve this question
6
  • 1
    What is your aim? Writing a paper about how to use a specific VCS in your company? Or document which versions of your software parts exists and which ones are compatible (which has not much to do with version-control, that's a more general thing called "configuration management"). Please clarify!
    – Doc Brown
    Sep 21, 2012 at 13:15
  • searching configuration management might help lead you to some useful things
    – Ryathal
    Sep 21, 2012 at 13:15
  • We are already using a VCS in our company. The goal is to match intern known versions with external software modules depending on our system and communicate this (some time in the future) to the customer. Doing this, we hope to get ride of some older and still used interfaces. - I'll inform myself a bit more configuration management, thank you for the hint.
    – Zwie
    Sep 21, 2012 at 14:03
  • What means "external" to you? Software of your customers? Do you really know what software they have written using your modules? What kind of "interfaces" exist for external use, and how stable are they? What life cycle does your software have? Does your customer contract even allow to change that interfaces? Do your write about desktop software, mobile, server modules, games, web software? I don't get the picture because of so many missing pieces of information.
    – Doc Brown
    Sep 21, 2012 at 15:09
  • Simplified: We provide an interface for webbased fameworks, which they implement in various modules. Since the version nr haven't been published yet, the customers implemented different versions without knowing - depending on the specification they got from us. Until now, there is no EOL - even the 10 year old versions are supported... I've to create (and further manage) a version overview, so that we hopefully can communicate the versions to the customers and set some EOLs.
    – Zwie
    Sep 24, 2012 at 7:27

3 Answers 3

Reset to default
6

Check out Semantic Versioning.

In the world of software management there exists a dread place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented...

I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

Improve this answer
2
  • Useful resource. In our case the head developer already set up a similar version labelling.
    – Zwie
    Sep 21, 2012 at 14:10
  • +1, really nice resource. I'd like to add the version numbers should be 100% transparent to the users of the public API and easily to determine if one forgot which version he has installed.
    – Doc Brown
    Sep 21, 2012 at 15:22
3

I don't know a rule for this, but in many cases version is composed of 2-4 numbers.

A version like 1.2.3.4 can be interpreted as

  • 1 - the major version, changing it will break compatibility
  • 2 - minor version, new features
  • 3 - bugfix version, only when a release contains bugfixes
  • 4 - build number, the internal number of the build, usually decided by an automated build system or continuous integration system.

As I mentioned, this is just one of many common solutions, and it is the one I would prefer.

Improve this answer
1

Well, if you aren't doing it already, you really need to use Version Control Software. I know that Fossil has nice built-in display of branching and merging. Git and Mercurial are hot right now, but Subversion might still be the most popular because it's been around longer. I bet there are plug-ins for Git that can make graphics out of the software history and perform analysis.

When you put the software into source control for the first time, you probably want to recreate the history of major releases. Presumably (hopefully, as in, "Please God, Please") they have zip files of the source to each major release. You unzip these and check the contained files into source control in chronological order. Then you have a history of branches and merges and major functionality that you can use with a plug-in to Git or Mercurial to generate pretty graphics.

It may take a few tries to get the initial check-in really right. I can't imagine you have more than one developer working on something without it being in source control. What are you currently using?

Improve this answer
2
  • We are using SVN right now, so the intern software parts are all managed by a VSC. The problem are external developed modules, which are depending on our software, but unsure about which versions - since our developer never published the versions... To make it more complicated, I should continue this countless modules in my "version overview" to show, which module uses which internal version.
    – Zwie
    Sep 21, 2012 at 14:06
  • Sounds like a lengthy and detail-oriented task - good luck!
    – GlenPeterson
    Sep 21, 2012 at 15:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.