[bt-devel] Development after 1.7

[Greg Hellings]

On Wed, Feb 11, 2009 at 10:19 AM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Quoting Gary Holmlund <gary.holmlund at gmail.com>:
>
>> Martin Gruner wrote:
>>> All the changes we make bring us further away from the initial 1.7
>>>  release state. In case of important bugfixes we will have to decide  if we
>>> should rather releae TRUNK as 1.7.1, which would be ideal, or  if we want to
>>> branch the 1.7 state (it has a tag, as all releases)  and implement the
>>> bugfix in BOTH the branch and TRUNK. Then we  could release the branch as
>>> 1.7.1 and continue to work in a  not-yet-releaseable TRUNK.
>>>
>
> I'm for minor bugfix releases in case the changes have to be fast. I don't
> care so much about the technical implementation, as long as it doesn't
> dictate and hinder the development. BTW, I would like to use 1.7.1/2... for
> feature versions and if there are plain bugfix releases they could be
> 1.7.1.x. But it's a matter of taste, I think.

Why would you go so far out into the versioning scheme?  If 0.0.0.x
are bug releases and 0.0.x are feature/UI updates you're still left
with two versioning numbers.  Are you going to say that 0.x is major
changes (i.e. move from KDE to Qt) and then what is left for the major
version number?  If you say that the major version number is for
things like the KDE->Qt port, then where does that leave the 0.x
number?

Personally I think that the model used by, eg the SWORD library and
the Linux kernel, where pretty much anything can change between 1.5.10
and 1.5.11 of the library or 2.6.9 and 2.6.10 of the kernel is a bad
design - it prevents the version number from meaning anything at all
except for chronological ordering.  But to take it all the way to 4
separate numbers as you suggest?  I think that's overkill - the 3
number release seems to be sufficient in my opinion, but keep
consistent that 1.7.x all have the same features where the only
differences is security, bug or other necessary fixes.  Let 1.8, 1.9,
etc be the next feature update release and let version 2 indicate
something very significant - like an abandonment of KDE in favor of Qt
and allowing for release of a supported Windows/Mac version of the
software.

--Greg