[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Application version numbers
From:       "Jason 'vanRijn' Kasper" <vr () movingparts ! net>
Date:       2009-01-22 15:35:59
Message-ID: e2a9b7d0901220735s22a50785pbd584848a0c6939e () mail ! gmail ! com
[Download RAW message or body]

On Thu, Jan 22, 2009 at 2:34 AM, Andreas Pakulat <apaku@gmx.de> wrote:

> On 22.01.09 04:49:41, John Tapsell wrote:
> > Is it possible to have an application version just simply be the
> > version number of KDE?
>
> Technically: Yes, those apps can simply #include kdeversion.h and use
> the defines for versions that are in there.
>
> Wether or not the app authors want that change is a different story ;)
>

KPilot has had a... creative... versioning scheme that went something like
X.Y.Z where X and Y were KDE version X+1 and Y+1, respectively. So, KDE
3.5.2 had KPilot 4.6.0. And then we've gone somewhat nuts since then with
version info and got up to version *"4.9.4-3510 (elsewhere)" *with KDE
3.5.10.

With KDE 4.2, I've tried to make a more sane version scheme, so this is what
we have for KDE 4.2:

#define KPILOT_VERSION  "5.2.0 (KDE 4.2.0)"

I think one reason that we've specifically not just followed KDE's numbering
scheme, is that there have been several times in the past where we've had to
release an interim bug-fix version of KPilot in between scheduled KDE
releases. Maybe KPilot is special in this regard in that most apps don't
have the potential of destroying anyone's data in new and exciting ways, but
there's one reason I can think of for not trying to get every app to just
use the same version number as the KDE release they're distributed with.
*shrug*

-- 
-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
-[ KDE PIM Developer         //  http://www.kde.org  ]-
-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-

[Attachment #3 (text/html)]

<div class="gmail_quote">On Thu, Jan 22, 2009 at 2:34 AM, Andreas Pakulat <span \
dir="ltr">&lt;<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On 22.01.09 04:49:41, John \
Tapsell wrote:<br> &gt; Is it possible to have an application version just simply be \
the<br> &gt; version number of KDE?<br>
<br>
Technically: Yes, those apps can simply #include kdeversion.h and use<br>
the defines for versions that are in there.<br>
<br>
Wether or not the app authors want that change is a different story \
;)<br></blockquote></div><br>KPilot has had a... creative... versioning scheme that \
went something like X.Y.Z where X and Y were KDE version X+1 and Y+1, respectively. \
So, KDE 3.5.2 had KPilot 4.6.0. And then we&#39;ve gone somewhat nuts since then with \
version info and got up to version <b><font color="#bc8f8f">&quot;4.9.4-3510 \
(elsewhere)&quot; </font></b>with KDE 3.5.10.<br> <br> With KDE 4.2, I&#39;ve tried \
to make a more sane version scheme, so this is what we have for KDE \
4.2:<br><br>#define KPILOT_VERSION&nbsp; &quot;5.2.0 (KDE 4.2.0)&quot;<br><br>I think \
one reason that we&#39;ve specifically not just followed KDE&#39;s numbering scheme, \
is that there have been several times in the past where we&#39;ve had to release an \
interim bug-fix version of KPilot in between scheduled KDE releases. Maybe KPilot is \
special in this regard in that most apps don&#39;t have the potential of destroying \
anyone&#39;s data in new and exciting ways, but there&#39;s one reason I can think of \
for not trying to get every app to just use the same version number as the KDE \
release they&#39;re distributed with. *shrug*<br clear="all"> <br>-- <br> -[ Jason \
&#39;vanRijn&#39; Kasper &nbsp; &nbsp;// &nbsp;<a \
href="http://movingparts.net">http://movingparts.net</a> ]-<br> -[ KDE PIM Developer \
&nbsp; &nbsp; &nbsp; &nbsp; // &nbsp;<a \
href="http://www.kde.org">http://www.kde.org</a> &nbsp;]-<br> -[ bash fun -&gt; :(){ \
:|:&amp;};: &nbsp;// &nbsp;Numbers 6:22-26 ]-<br>



[prev in list] [next in list] [prev in thread] [next in thread]