Re: [ecasound] we need bigger releases!

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] we need bigger releases!
From: Jeremy Hall (
Date: Wed Feb 07 2001 - 03:50:38 EET


I think people should use the 1.9, 1.10, etc versions as stable releases
and 1.9.1 etc as devel, just as you have suggested. You might leave the D
in there just to make sure people realize it is a development release and
not a release release.

I also think people wishing to test a new feature should use CVS, that way
if there are problems, the latest CVS tree is always available. If a
person is questioning whether his development release is current, he
should do a cvs update and ensure he has current files.

You could have symbolic tags in the CVS to denote some stage
(before_mixer) for example comes to mind. People wishing to bleed should
do so on CVS so they remain current with the code.

just my $0.02


In the new year, Kai Vehmanen wrote:
> 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
> identify.
> 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 ...
> --
> . ... [ audio software for linux ] /\ .
> . [ my armchair-tunes mp3/ra/wav ]
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <>.

To unsubscribe send message 'unsubscribe' in the body of the
message to <>.

New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Feb 07 2001 - 03:53:05 EET