Nicolas picked up on the reason I
suggested 0.x.y version numbers that get incremented. The way the update
manager is configured by default, it will automatically select versions with an
incremented service version (the “y” part above), but not updates
with a new minor version. This makes sense based on the conventions, because
a service update is supposed to be API- and functionally-compatible, but a
minor update can introduce substantial change. Assuming we want to use
the update manager, we need to increment the versions. Since we can
expect substantial changes on a regular basis before we get to release quality,
the versions will probably increment a lot. If we start from 1.0 and go
up, we might give an impression of maturity that doesn’t exist. For
example, I think “0.14.3” would indicate our current status better
than “1.14.3”.
Overall, though, this is a very minor
point. If other people prefer to start at 1.0, or don’t want to use
the update manager at all, I won’t raise a fuss about it.
On a slightly different tack: Aren’t
we supposed to plaster everything with “incubation” labels, so that
we can use the parallel IP process? That seems like a pretty easy change
for the current build process. Also, we’re supposed to put the “egg”
image on our main project site.
Peter