[bt-devel] Development after 1.7

[Greg Hellings]

On Thu, Feb 12, 2009 at 12:57 AM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Quoting Greg Hellings <greg.hellings at gmail.com>:
>
>
>>
>> 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.
>>
>
> That's true. I noticed in older release notes that some kind of consensus
> was "2.x" for Qt-only releases. Possibly 2.0 for Qt-only Linux version and
> later 2.1 for Windows and maybe Mac version, in the order they are ready.
>
> Another possible scheme was to release Qt-only as 1.8 and crossplatform as
> 2.0. If that's the case, then we would need 1.7.x for feature releases and
> 1.7.x.x for minor bugfix releases. But I like the first scheme.

Oh yes, I had forgotten about the second possibility there.
Personally I see the KDE->Qt port as the more intense and significant
change - indeed, the Linux->XPlatform move is almost entirely summed
up in getting the Qt port working.  After that it will probably be
just minor best-practice adaptations to each platform (but I could be
wrong about that).  Thus it would seem to me that labeling a Qt-only
version as 2.0 and, if necessary, holding cross-platform till 2.1
would be preferable.  However, from the user's perspective, probably
the move to Qt is of negligible importance if the program doesn't
appear on Windows and Mac, so that would tend to suggest that
releasing a 1.8 (or possibly 1.9 - I've seen some projects use an x.9
release to indicate that moving in a new direction is under way, sort
of like saying it's stable on all the places it's been stable before,
but in its new places it's still part-beta) under Qt while those
little details of the cross-platform are worked out.