James Harris wrote:
> Is there any mileage in devising a general application version
> numbering scheme and providing sup****t this in a programming language?
> The reason for asking is that it seems useful, in terms of managing a
> computer system composed of many modules, for the components of that
> system to have at least
>
> <user version info>.<feature>.<fix>
>
> where
>
> <feature> increments on each /release/ of a new feature set
> <fix> resets to 0 or 1 on each feature change and increments on
> each released bug-fix
>
> The user version info would be arbitrary so could include higher level
> version numbers or not as needed. For example, MyApp.2.1.4 would be a
> release of "MyApp.2" feature set 1 and fix version 4.
>
> Why offer sup****t for this in a programming language? For two reasons,
> 1. it provides intrinsic sup****t for releases of standard (and
> possibly other) libraries for the language; 2. it offers this sup****t
> to applications (and system programs) written in the language. These
> are only worth doing if the scheme is general enough.
IMHO, no scheme is likely to be general enough that having a single
scheme is sufficient most of the time. No matter what assumption you
make about release cycles (and relation****ps that "always" hold between
one release and another), your assumption will ultimately be violated
eventually (and then your model will break).
I think what I'm saying is that programming languages are so general
(or should be so general) that trying to solve this problem in the
programming language seems like a bad idea. Ultimately, it's the
environment and circumstances of an individual application (or
"project", whatever term you want to use) that determine the needs
for a scheme for naming releases. And hopefully a programming language
is general enough to be used for multiple different types of applications
with different needs! (Well, ignoring domain-specific languages.)
To make that a little more concrete, some complications you might
see are:
1) Some applications might not choose to define a total ordering
of version numbers. It's simpler to comprehend if all development
proceeds along a single line, always marching forward towards the
end-state of perfection. But in reality, customer A demands an
immediate fix for bug 1 and customer B doesn't care about bug 1
but does demand an immediate fix for bug 2. Fixes for bugs 1
and 2 go into version N+1, but there is no inherent ordering
between bug fix 1 and 2. You can ignore this issue by speaking
of only "official" releases, thereby forcing everything into a
nice linear sequence of releases, and maybe that's all that you
care about. But whether you want to force everything into a
single sequence is something that depends on the software.
For example, some software is developed without any customers
in mind, and in that case, a linear model is easy enough to
maintain.
2) The semantics of the actual version number vary between one
piece of software and another. In the standard Linux-inspired
versioning scheme, versions are a list of numbers, and there is
some number in the list which has a special status so that odd
numbers mean "unstable" and even numbers mean "stable". For
example, in the Linux world, kernel version 2.6.25.2 is
(nominally) stable, but version 2.5.x is not. The difference
lies in the fact that *second* number is odd. Of course,
it would be just as valid for some other project to define
8.x as stable (because 8 is even) and 9.x as unstable (because
9 is odd. To put this a different way, every project has a
function mapping version numbers to meanings, and that
function tends to be different for different projects.
The reason this is significant (to me) is that the ability
to manipulate version numbers (other than as opaque strings)
rests largely on being able to assign meaning to different ones.
Because of all this, if one were to try to "solve" the version
numbers problem (and I use quotation marks because I don't know
if it is ultimately solvable in the general case), there would
be a lot of custom, per-application behavior required. Therefore,
it seems like trying to move this into the language is probably
a bad idea, unless it is done in a very general manner. And
by "general", I mean allowing the individual application to define
relations between version numbers ("X is more stable than Y",
or "A has more features than B", or even "C is the freeware
version of "D"), allowing the rules to change over time, and so on.
- Logan
P.S.: On the other hand, there can be some value in a language
providing direction and forcing 95% of the applications
into a certain mold. At least insofar as the applications
don't have any strong preference of their own.
|
