Subject: [ecasound] we need bigger releases!
From: Kai Vehmanen (firstname.lastname@example.org)
Date: Wed Feb 07 2001 - 03:38:41 EET
Warning! Don't take this too seriously. I really should be studying
"automata and formal languages" at the moment, but for some reason
ecasound's version numbering just seems much more interesting. ;)
Someone complained that it's difficult to identify ecasound stable
releases. And the more I think about this, the more convinced I get that
he's right. Now that ecasound has two-digit version numbers, stable
version numbers have become quite awkward. For instance, after months of
development I will be releasing "v1.8.7r15" ... now without knowing about
the versioning policy, this doesn't seem like a big release. So how to
improve to situation?
My proposal is to drop the 'rXX' suffix (and optionally the last '.X'),
but keep a variation of the 'dXX' notation -> 'devXX'. So we'd have
development versions 'ecasound 1.9dev1', '1.9dev2', ..., and eventually a
stable 'ecasound 1.9'. If for some reason the stable release needs small
changes or improvements, '1.9.1' would be released.
One goal of the above notation is to make a clear distinction between
stable and devel releases. On the other hand, stable versions are easy to
Another goal is to simplify and streamline the development process.
Nowadays I spend way too much time thinking about what to release and
when. And this not good at all. The whole process should be as
lightweight as possible. Whenever someone sends a patch or I write code
myself, I should be able to make some kind of release right away. There's
no need to hold back new features.
What do you think? It might just be that I will skip 1.8.7r15
altogether and go to 1.9 instead, and then start working on either
1.10dev1 or 2.0dev1 ...
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
-- To unsubscribe send message 'unsubscribe' in the body of the message to <email@example.com>.
This archive was generated by hypermail 2b28 : Wed Feb 07 2001 - 03:42:43 EET