Suggestion about dolphin versions

[Todd Rme]

On Fri, Jun 14, 2013 at 5:24 PM, Frank Reininghaus
<frank78ac at googlemail.com> wrote:
> 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 ;-)

Perhaps, I have no role in the decision, I have just seen it being discussed.

>> 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 am saying the decision on whether to support an frameworks-wide
version numbering scheme will probably be made in a matter of months.

> 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.

Again, I really don't know myself, I am just pointing out that this
might (or might not) become an issue, so should probably be kept in
mind.  Even if you decide to go with the current upstream version
numbering, if this is removed you can still just continue with the
numbers where they left off. But since it is something that is being
seriously considered, I thought it worth bringing up just in case it
has some impact on the decision.