Should you version web applications?

If you resell the same web application to multiple customers, you absolutely should version it.

If it's a website that's only ever installed in one location, then the need is less dire, but it still likely couldn't hurt. You'd be less susceptible to timezone problems and such, too. Diagnosing an issue in a library version 1.0.2.25 is a lot nicer than hunting down the library build on November 3, 2010 11:15 a.m.

If you can automate version number on your application's DLLs, it couldn't hurt. It will help you keep track of versions.

Generally, web apps are released only at one location where you are hosting it, so it's not as important as say a desktop application. It can help with roll-backs, bug tracking (i.e. which version was this in) and keeping track of the difference between developer, staging, and production servers, if applicable.

I'd look into automating it - it's the kind of thing you can setup once and use it if/when you need it.

In addition to what the others have said, I'd add that versioning is also important from a marketing perspective. A new version is something new that can be marketed to potential or existing customers. It lets customers know something is 'new' and see that things are moving forward. It provides nice groupings of new features. And it looks more professional.

Your users doesn't care about version numbers as they always have the latest and greatest release anyway, but you owe it to yourself (and your team) to know exactly what version is running live. Eventually your development source gets out of sync with the live code and then you definitely must know. So label your releases in your svn/git tree and mark the web app with that tag.

If you have a dev/test instances it is pretty important for project team members to able to see which build/revision they are testing.

You should version your web application with the build id from your build server and have that id enclosed in all bug reports.

This will allow you to go back in time in case you have to fix a bug reported on an older version not currently present in production.

• Internal use only with limited install base?
• Or liable to have multiple versions in the wild?

We only have the former so only use the version number for sanity checking post release. We don't have to track many versions in use at the same time.

If your web application consists of multiple modules, both in client and server, each module should be versioned. And each combination of module versions on both client and server should be given an unique id, an id that should be present in all logging and error messages.

By using that convention, it will always be possible to recreate the state the web app was in at a given moment.

In my opinion, since webapps these days are built using dynamic languages on both sides, server and client, there shouldn't be any reason for reloading an updated web app unless the user restarts the browser or manually reloads the page.

Only the updated parts or modules in the web app should be reloaded without affecting the overall state of the application.

Why you might ask? Well, by enforcing that, the web app will by its design be more roboust, correct and probably easier to maintain. If the web app always require simultaneous server/client update then it probably is not build the right way.

I say that for anything but a trivial web application, you should version it. There are two, slightly different, notions at work here:

1. application as a whole
2. individual files

Regardless of the situation, I believe that files should have individual version (or revision) numbers. Ideally, this would be handled automagicaly by your version control system. As it has been stated by others, it's easier to refer to a file's version number than its date-and-time.

If you have (or may have) more than one live installation of the application, it should be versioned as a whole. This is also a good practice if you have separate dev and test environments (as you likely should). Each application (or release) version number refers to a collection of individual files at specific version numbers. While dealing with all of this is an extra burden, it is easier to check-out a specific release than individual files at specific revision numbers.

This makes me think of a notion in linguistics. It is said that if you can't express something in a language, you can't think about it (in that language). I think of the German word 'Schadenfreude.' It is much easier to think (and speak) of this notion of "feeling joy due to someone else's misfortune" by referring to that word, than its definition. That is the reason the word has crept into use in the English language.

Similarly, version numbers make it easier to speak (and think) of your application and its files at specific states. If you're a one person team, working on one application, it doesn't likely make a huge difference. However, as things get more complicated it is better for you to have these labels available for use.

Yes, you should version it! And there should be a tag in your revision control system (like subversion, git, mercurial, etc.) that matches the version number.

The tag allows you to go back and make a branch. For example: the current production version has a bug, but you can't fix it because the code on your machine just isn't ready to roll out the door. If you have it tagged in your RCS though, you can branch at that tag and fix the bug in the exact version of the code that's running in production.

Personally I think you should version anyway, but one big benefit of versioning web applications that is specific to websites is that it can make changes to static content much easier to manage.

For example, let's say you have a mysite.css file which has a far future expiry date (which you generally want to do so that it's cached in the browser across each page). If you then change a style in that file no-one who has been to your site before is going to see it unless they do something to clear that file from their cache.

If you're versioning you site though you could change all the css references in your build to something like mysite.css?v=1234 which will let you keep the far future expiry date and not worry about future changes as in the next build it'll be mysite.css?v=1235.

Yes you should. For distribution reasons pointed here by other answers.

But I see, why you asking the question. Web apps approach is cost driven. Its opposite to legacy shrinkwrap approach, where costs include physical media, distribution, installation, hardcopy of documentation, training and technical support. Anything which can be excluded, should be excluded.

Just to be clear, I'm assuming that you are talking about a user-visible version number of some sort, and not giving up on version control in development. (if you think you don't need version control in development, then you are wrong, you do need version control).

For a single-hosted project it's not strictly necessary, because if any questions arise you can always look at the host and confirm what's really running. It's kind of nice, though, because it might come in handy once or twice. It's really up to you as to whether you think it will be useful or not.

For a multi-hosted project, it's not really optional. Different hosts will eventually end up with different versions and you'll need to be able to tell them apart at the user end.