I've been thinking about this again and I think I'm going to do
it during 1.8.x development. One of the biggest reasons is that
qtecasound is starting to slow down other development. Ecasound itself
is at the moment quite stable (something you'd expect by looking at
its version number). On the other hand qtecasound isn't something
you'd expect to find in 1.x or 2.x versioned package.

So we'd have ecasound 1.8.x, qtecasound 0.1.x and ecawave 0.2.x. I think
these version numbers reflect the current situation quite well.

Ecasound is getting bigger all the time, and the current binary-rpm is
starting to be a bit too big. One way to solve this would be to split
console-related and qt-related stuff in separate packages. Binary packages
are already separate, so this would only affect the source
packages. Ecasound, libecasound and ecatools would remain in the current
source tree, while qtecasound and libqtecasound would have their own dist
package. Ecawave would continue to be a totally separate app.

Opinions?

PS This might also help people to understand, what ecasound really is.
Lots of people think that either a) ecasound is just another Qt-app,
or b) it's just console mode tool for converting sound files. The
latter one was how a certain Finnish computer magazine described
ecasound. ;)
PPS Ecasound now and then reaches the top-100 list at sourceforge.net! :)
You can see the list at ...
http://sourceforge.net/top/toplist.php?type=pageviews_proj
You won't see ecasound in the other stat pages because
ecasound's mailing lists and primary file servers are not
at sourceforge.net ... oh, well, vanity, I know, but I just can't
help myself. I have to check the latest top-100 listing every day. ;D