Web-App : Keeping trace of the version of the application in database?

We are building a webapp which is shipped to several client as a debian package. Each client runs his own server. But the update and support is done by us. We make regular releases of the product, with a clean version number. Most of the users get an automatic update (by Puppet), some others don't.

We want to keep a trace of the version of the application (in order to allow the user to check the version in an "about" section, and for our support to help the user more accurately).

We plan to store the version of the code and the version of the base in our database, and to keep the info up to date automatically.

Is that a good idea ?

The other alternative we see is a file.

EDIT : The code and database schema are u开发者_运维问答pdated together. ( if we update to version x.y.z , both code and database go to x.y.z )

Using a table to track every change to a schema as described in this post is a good practice that I'd definitely suggest to follow.

For the application, if it is shipped independently of the database (which is not clear to me), I'd embed a file in the package (and thus not use the database to store the version of the web application).

If not and thus if both the application and the database versions are maintained in sync, then I'd just use the information stored in the database.

As a general rule, I would have both, DB version and application version. The problem here is how "private" is the database. If the database is "private" to the application, and user never modifies the schema then your initial solution is fine. In my experience, databases which accumulate several years of data stop being private, it means that users add a table or two and access data using some reporting tool; from that point on the database is not exclusively used by the application any more.

UPDATE

One more thing to consider is users (application) not being able to connect to the DB and calling for support. For this case it would be better to have version, etc.. stored on file system.

Assuming there are no compelling reasons to go with one approach or the other, I think I'd go with keeping them in the database.

I'd put them in both places. Then when running your about function you quickly check that they are both the same, and if they aren't you can display extra information about the version mismatch. If they're the same then you will only need to display one of them.

I've generally found users can do "clever" things like revert databases back to old versions by manually copying directories around "because they can" so defensively dealing with it is always a good idea.