Separate the floating "latest" version from the latest version-in-progress

[Leonard Richardson]

In Launchpad, the latest version of the web service is always called "devel". The idea is that periodically we will give "devel" a name, replace all references to devel with references to that name, and start creating new stuff for "devel".

The periodical step where we change the references is kind of a pain, and it's easy to avoid with a simple change. Name the new version _as soon as it's created_. Call it "1.1" and start creating references to 1.1, with the understanding that 1.1 is in development and won't be frozen until it stops being the latest version.

"devel" will still be around, but it will never be used in web service annotations (and as such will never have to be changed). It will just be a helpful alias for clients (including the Ajax client) to use when they want to track the trunk's web service behavior.

[Leonard Richardson (leonardr)]

The downside of this solution is that we have to decide on the version number ahead of time. We won't get the luxury of deciding at release time whether this is a 1.1, a 1.5, or a 2.0.

This actually ties into an idea I had a while ago, of giving the web service releases alphabetic names (like Ubuntu release names), to convey the feeling of steady progress without making any promises about the _magnitude_ of the progress per unit time.

[Robert Collins (lifeless)]

Having experimented with deciding early or late for similar things in bzr, I think it would be a grave mistake to decide on the version in advance.

The reasons for this are varied:
 - sed is actually pretty good at changing things (its not expensive to decide late)
 - when you name something users /will/ start having expectations about stability unless the name is clear that its unstable (and this bug is about avoiding renaming)
 - telling the future is very hard

Further, while we could add a double-dereference layer (e.g. we say 'api-23' in code and have that exported as '1.2' in wadl), that just adds overhead to the already immense overhead involved in importing launchpad and getting going. We should think very seriously about doing that.

My current inclination is to wontfix this. What do you think? Do my points make sense?