Mike B. Allen in news:comp.unix.programmer am 30.1.2002

(Über Versionsnummern und einfache Sicherung)

The inception of a project is likely just a handfull of source files. Just create a directory like 'crap' and get coding. Get your ideas out of your brain and don't worry about version numbers.

When you have something worth working on create a new project directory like foo-0.0.1. Notice the format here is name-maj.min.rev where name is the name of the project or program, maj is the major number, min is the minor version number and rev is the revision. I advise against using foo_0.1 or foo-156 or other fandangled permutations. Of course the code is really what matters but this is by far the convention of choice used by developers. Note, the major number should only change when the project has undergone significant changes like a total rewrite or API changes. The minor number should be incremented whenever you break binary compatibilty. This is important to versioning of dlls. If you only change the rev (like when you make a little update), you don't have to worry about recompiling code that uses your dll. (actually I could be a little wrong about this but I'm sure someone will correct me :).

Now that you have a fresh foo-0.0.1 do some work and at the end of the coding session, create a tar.gz and then rename the directory to foo-0.0.2 and put the tar.gz somewhere where it will hopefully get backed up that night (a multi-session CD would be a good poor mans backup solution). Now the next time you go to work on that project do you work on the foo-0.0.2 and at the end of the session do the same thing; create a foo-0.0.2.tgz, copy it to backup and rename the foo-0.0.2 directory to foo-0.0.3...

Evenentually you will reach a point where your program actually sorta works (hurray!). At this point you can now create one more tgz called foo-0.0.15 perhaps, copy that to backup and rename the direcory to foo-0.1.0. Again the cycle continues.

Depending on the size of the project, the code should be genuinely useable by the time you get to foo-0.5.0. When the code *really* works, you have API documentation, a small OpenSource fanbase, and it's been tested, you can release it as foo-1.0.0. At that point versioning really get's wild.

It's hard to tell the state of a project after that. Some people just increnent the number because it *feels* like the right thing to do. At work, we increment the version number on a project when we need to show management that we're making progress.

Kleine Anmerkung: Mike vermischt zu Beginn die Versionierung von DLLs (unter Linux SharedObjects? genannt) und Projekten, obwohl diese Versionsnummern eigentlich voneinander unabhängig sind (sein sollten).

Für Details empfiehlt sich das Studium der libtool Dokumentation.