texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] versioning scheme


From: david
Subject: Re: [Texmacs-dev] versioning scheme
Date: Tue, 8 Apr 2003 10:06:55 +0200
User-agent: Mutt/1.5.3i

On Mon, Apr 07, 2003 at 06:55:07PM +0200, Joris van der Hoeven wrote:
> I don't understand what is so unconventional about it.
> Major releases are of the form a.b, stable releases of
> the form a.b.c and unstable releases of the form a.b.c.d.
> That seems pritty standard.

Can you point us to other software which use that number scheme?
I have never seen one before texmacs.


> I even think that the linux kernel releases, which were
> mentioned before, have a really odd numbering scheme :^)

In the world where I lived before I become a linux folk (that is the
macintosh world) releases were numbered as:

a.b.c-xxx

A. only increased when major features are added or major parts are
   rewritten.

B. increased when minor features are added, interfaces are preserved.

C. bugfix and compatibility releases.

xxx. something like a1 (alpha 1), b5 (beta 5) or rc2 where (release
candidate 2) where:

  o alpha are development releases, known to be unstable and
    incomplete.

  o beta are debugging release for testing, the interfaces are frozen
    but features are still added.

  o release candidate are releases occuring during feature freeze.
    Since beta is a kind of soft freeze, it is not always necessary to
    have rc releases.


That makes a clear distinction between production and development
versions. I think any computer folk knows that alpha and beta releases
yield radioactive particles which make a computer unstable :-)

According to this scheme, TeXmacs 1.0.1 would have been 1.1, and the
next stable would probably be 2.0 considering the amount of rewriting
currently being done.

No bugfix release means simply no A.B.C releases. If someone has an
interest in maintenance releases, the subminor number would be there
to be used.

Last note: versioning is not cast in stone, and has a marketing
significance. We really should not be too modest. Say 1.0.1 was
released one year after 1.0, and many people will have the impression
that almost no dev is going on the project. Say 2.0 was released one
year after 1.1 and you give a totally different impression.

                                                            -- DDAA




reply via email to

[Prev in Thread] Current Thread [Next in Thread]