Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In Google App Engine, you can upload up to 10 different versions on your appspot project. For instance, if I have a project called example, the URL would be:

Each version I upload is given a version string. Possible examples are:

  • dev
  • 1
  • 1_2
  • staging
  • anystring

To access a specific version, I would prefix the domain with the version string, like so:

Of course, if that version is made the "default" version, then I can access it without prefixing with the version string, such as in the original URL at the beginning,

What are the current best practices for managing version strings on Google App Engine Apps, in your experience? Also, once I surpass the max 10 versions and have to start deleting them, what is the suggested practice?

share|improve this question
We use versions like 42-checkout-fix. Number gives ordering, and name tells what was changed. Also, you can upload up to 60 different versions, not 10: – Dzmitry Lazerka Mar 1 at 9:19
up vote 3 down vote accepted

The main issue is to make sure your release engineers (who may be the same as your developers) don't get confused about which version is which. Sequential build numbers (1, 2, 3, 4, ...) are usually fine for small projects. Using the date that you deployed the code (2011_05_29) would also work well.

If you have multiple developers and they deploy versions not intended to become the live version, calling them something like "myusername_test" will help avoid accidentally deploying it.

Sometimes there are special versions that aren't for testing but for a specific purpose. For example, sometimes I have a version named "down" which we make the default when we want to take the site down for maintenance. Or there could be an "admin" version, etc.

To be really safe you should use a different app id altogether for testing. Often each developer has his or her own app id. However, this requires either populating it with test data or copying the data from the production app id.

With regards to deleting versions, I would always keep one or two versions behind the live version just in case, but it's up to you.

share|improve this answer

Anything as long as it matches your commit message. I have saved myself a couple times by getting into the habit of saying what version it is deployed as before actually deploying.

I personally use something simple like crm-12 or blog-37

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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