>> What exactly is your argument for *not* going to version 3.x in
>> that case?
>
> [...] Since this doesn't break backward compatibility, I don't
> think we need a major version bump.
IMHO, a major version bump should also be used if something changes
fundamentally, regardless whether it is backward compatible of not.
The introduction of the Cairo backend as the default is such an event.
LilyPond is not a library, we are thus not bound to reflect the DLL
version number in some way. Also, many other software products do the
same, including other GNU projects – a new major version number is
kind of an advertisement.
At the current maturity level of LilyPond I don't see that we are ever
going to change the syntax in such a radical way that it would deserve
a major version change. Additionally, my gut feeling says that the
minor version number is already uncomfortably high.
The alternative is to drop the major number completely, as was done
for Emacs, Firefox, or the Linux kernel, to name some well-known
projects. However, then the major version number gets uncomfortably
high... But maybe it's only me who thinks that :-)
Werner
