Consider bumping version number to > 1.3.4

[smcv]

I used to maintain the old rgain package in Debian, and I'm now looking at packaging rgain3 as a replacement. rgain3 1.0.0 is a continuation/fork of rgain 1.3.4, so it seems potentially confusing that the version number has gone down.

In particular, because the git repository already contains tags for versions like 1.0.1 and 1.2, it will not be possible to reuse those version numbers, which might lead to some odd versioning in future.

It might be less confusing all round if this fork started from version 2 or 3 (or 1.4 or something) so that the version numbers are monotonically increasing.

[chaudum]

I used to maintain the old rgain package in Debian, and I'm now looking at packaging rgain3 as a replacement. rgain3 1.0.0 is a continuation/fork of rgain 1.3.4, so it seems potentially confusing that the version number has gone down.

I've thought about starting with version 3 when I did the first release of rgain3 (see #6 )

In particular, because the git repository already contains tags for versions like 1.0.1 and 1.2, it will not be possible to reuse those version numbers, which might lead to some odd versioning in future.

That is a good argument!

It might be less confusing all round if this fork started from version 2 or 3 (or 1.4 or something) so that the version numbers are monotonically increasing.

I would rather use version 3 than 2, and I am happy to do so with the next release.