Version Numbers

[Jecel Mattos de Assumpcao Jr.]

Does anyone know a good scheme for version numbers for a
complex piece of software such as Tunes?

The current xx.yy.zz.vv system is interesting, but has most of the
same problems as the schemes I will mention below.

At one time I tried simply using the release data as the version
name. That gave a relative ordering to the versions, but most
development is not very steady, so it is hard to tell how much
two versions differ using this system. You might just do a minor
patch in two years, or a major overhaul in three months.

A single number, like the Adobe Postcript interpreters have, has
the same problems as using the dates.

The Revision Control System ( RCS ) that comes with Linux uses
a two level system: 1.3, 1.4, 1.5, etc... The first number is
incremented manually to indicate a major release. To allow
several people to work on the project at the same time, you can
create derived versions. If you derive a version from 1.4, for
example, you get 1.4.1.1. The next change you make to a file
will result in 1.4.1.2 and so on. This allows you to build an
arbitrary version tree ( actually a graph, as different branches
can be manually merged to create a new version derived from both ).

The major problem I see with RCS is that is works with versions of
the individual files. What about the whole system? How should it
work in a hierarchical project like Tunes? If you update the
Interfaces project but keep the HLL project as is, for example,
should the system version number be incremented? Should each
subproject have its own version number?

In my 286 OS ( back in 1987 ) I adopted the system decribed in
"Managing the Evolution of Smalltalk-80 Systems" by Steve Putz
in pages 273-286 of the book "Smalltalk-80: Bits of History,
Words of Advice" edited by Glenn Krasner ( Addison-Wesley 1983
ISBN 0-201-11669-3 ). That system started out as informal practices
using email and evolved into a tool based system. The main
elements were:

   bug report - a message detailing a bug found in a given version
                of the system. It might also be a suggestion for
                improvement ( in my use of the system, at least )

   change - a message describing changes made to one or more source
            files ( which are listed ) to fix one or more bugs as
            described by the listed bug reports

   version - a message that talks about the release of a new version
             of the system that is derived from a given version by
             adding the listed changes

Browsers allowed you to create bug reports, changes, versions ( each
with a unique ID given by the system ), anonymous test versions, to
look at these elements, to find relevant bugs for a version and so on.

When creating a new version, the system might warn you of conflicts
in several changes. The solution was to create a new change manually
that resolved the conflicts and to use it instead of the original
changes in the new version.

Changes that were not incorporated in a version were known as "goodies".
The system allowed you to try them out ( one at a time or in combination )
by making a test version.

This was a very neat system, but it also had a "flat" view of the
software, where a change to any part has the same effect on the
version number.

Isn't there any way to combine version numbers with the subproject
numbering scheme in Tunes to be able to say things like "a system
with old garbage collector and new GUI"? I wouldn't mind if the
resulting code turned out to be very large - we might build some
browser to filter it.

So, we have:

                          Date  Number  RCS   Smalltalk   What I want
----------------------------------------------------------------------
imposes order             yes    yes    yes(1)   yes       yes(1)
quantity of change        no     no     yes      yes       yes
tree of versions          no     no     yes      yes(2)    yes
file based                no     no     yes      no(3)     no
hierachical               no     no     no       no        yes
----------------------------------------------------------------------
(1) only within a single branch
(2) allows anonymous test versions, not a real tree
(3) changes are file based, versions are not

How about it folks? Is it even worth wasting time worrying about this?

regards,
-- Jecel Mattos de Assumpcao Jr
   Laboratorio de Sistemas Integraveis - University of Sao Paulo - Brazil
   jecel@lsi.usp.br     http://www.lsi.usp.br/~jecel/jecel.html