How do you avoid forgetting to increase version number for your project? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

开发者_如何学编程 Improve this question

I always forget to change the version number for bugfix version, when i released 1.0.9, maybe the version number in source code is still 1.0.0

So far it is not a big matter as every release was logged in SVN, i can retrieve a specified release anytime from my SVN.

But i know its not good, and in foreseeable furture it may cause problem when upgrading an old version. I stored the version number as a parameter in my source code, i wanna if there is a better way to control this number, especially for php web project (i know some other language has auto version generation, but seems no in php?).

How do you cover this problem in your project? Any best practice?

---

Use continuous integration software like TeamCity, and use a build script that accepts the version number as a parameter. Your build script may just call a little tool that just does: open a file (versioninfo.php), search this string (some regex stuff), and replace it with the given parameter.

---

Some additional hints for making this more easy: Branch every version that is soon to be released, we have 5.0 on production right now (but it's still built for the purpose of hotfixing), 5.1 is branched and is tested at this point, and the trunk contains the 5.2.

Everytime you will need to release a hotfix, update the version number in TeamCity, and in the call to the build script (which also should be done in TeamCity).

F.e. We have the following projects at this point:

• Release 5.0.5 (which takes /v=5.0.5)
• Release 5.1 (which takes /v=5.1)
• Trunk (which takes /v=5.2)

Combine this with prefixing your SQL scripts with the version number, and an automated database generating script, that creates a big transaction script per version (like: 'DPL_Updates_for_5.1.sql').

When we are bringing a version to production, we take the artifacts from the branch from TeamCity, the database-scripts which are specific for that version are automatically added to the zip-file, and we give the file (plus release notes, etc.) to our application management department.

---

You could use plugins like the Code::Block's AutoVersioning plugin which automatically increment the build number (and/or version number).

Or (if you've got too much time) you can create a SVN script that restricts commits with the same version number ^^.

---

Have a local database describing releases. Then write a script to build a release, and this can verify the version number stored in your source and update the database if the release succeeds. You may even gain a Joel Test point!

---

I have not used svn and php much. But I have seen some people integrated the svn version directly to the php file using documentation some thing like /** @version $SVN */ So that when ever we check out from the trunk our branch to create a build for release. The files contains/shows the current version.

---

Use phing to build your release package. It does have very flexible conversioning, it even can read SVN last version automatically.

---

Make a checklist. Follow it every time you release.