Suggestion about dolphin versions

[Frank Reininghaus]

Hi,

2013/6/14 Todd Rme:
> On Fri, Jun 14, 2013 at 12:30 PM, Frank Reininghaus
> wrote:
>> 2013/6/14 Jekyll Wu:
>>> I would suggest switching to the "x.y.z" scheme in KDE SC 4.11 , for the
>>> following following benefit:
>>
>> I fully agree that this makes a lot of sense. But I think the best way
>> to do it is to simply use the KDE version also for Dolphin (I think
>> Gwenview did the same thing recently).
>>
>> I see that Konqueror does this by simply using KDE_VERSION_STRING in
>> KAboutData (see KonqFactory::aboutData()). Maybe we should do the
>> same? This would mean that we never have to update the version in the
>> code again. This has the disadvantage that the version might not be
>> correct if a user builds Dolphin with a newer kdelibs (which is always
>> possible) or with an older one (which is possible if the minimum
>> requirement is fulfilled). But I think that this happens very rarely.
>>
>> Does anyone have any objections?
>
> Will this still work with Frameworks 5?

To be honest, I don't know. However, if there will be no such thing as
a global "kdelibs version" or "kde frameworks version" any more, then
triaging bugs in applications that depend on multiple "frameworks"
will probably turn into such a horrible nightmare that the present
discussion becomes meaningless anyway ;-)

> From my understanding there
> may not be full KDE SC releases anymore, with each project working on
> its own schedule.  I am not sure it is the best idea to switch to a
> numbering scheme that may very well be deprecated in a matter of
> months.

Do you mean that a stable KDE Frameworks version will be released "in
a matter of months", or a Frameworks-based version of Dolphin? I would
say that the former is very unlikely, and the latter impossible.
(Off-topic remark: I'm curious how far the "each project on its own
schedule" idea will really go. I cannot imagine that an approach where
every single application has to manage its own release process will
work).

We could also just call the next versions 2.3.0, 2.3.1, etc., but then
someone (probably me) would have to remember to update the version in
the code every single month and resolve the merge conflicts. It's not
going to be much fun, and it will cause trouble if it's forgotten or
done incorrectly once in a while. That's why I thought just using the
kdelibs version would be easier, and to be honest, I don't think many
users care if the next Dolphin version is 2.3 or 4.11.

Even if it stops working in the frameworks era, and we just call it
"Dolphin 5.0.0" then, I don't see a big problem.

But there's still some time until the next beta release, so we can
still think about it.

Cheers,
Frank