Plasma Next Naming

[Martin Klapetek]

On Sun, Jan 19, 2014 at 10:02 AM, argonel <argonel at gmail.com> wrote:

>
> On Sun, Jan 19, 2014 at 2:00 AM, Martin Graesslin <mgraesslin at kde.org>wrote:
>
>>
>> But of course the main idea behind the version pattern change to a date
>> based
>> version number is to add more information to it. The main problem with
>> version
>> numbers is that they don't carry any information and nobody knows how old
>> that
>> version actually is.
>
>
> I'd say this is not entirely true. Paired with the currently installed
> version number, you can tell:
>
> - How "far" your system is behind
> ---> e.g. have "1.1.2" and the update is "1.1.4" --> "Whoops, missed an
> update there, better look into that"
>
> - How important/interesting the update is
> ---> e.g. have "1.1.2" and the update is "1.1.3" --> "Ok, I don't need to
> do this right now," or conversely "I can do this update now because its
> unlikely to cause any serious issues"
> ---> e.g. have "1.1.2" and the update is "2.1" --> "Whoa, really out of
> date, maybe this showstopping bug is fixed!" or conversely "I'd better not
> do this update until after I finish the project that's due tomorrow"
>

Depends on when does the user get the "update" info from. If from distros,
in 99% of cases you won't have update from 1.1 to 2.x in the same distro
release, because politics and stability and things. If by "update" you mean
for example KDE.news, then the user has to be aware of such channel. On the
other hand, if the version is date based, the user can spot immediately how
out of date he is. More below.


> Whereas with dates you have two dates and can only tell the number of days
> between them. You'll have to find a list of releases to know if the system
> you're sitting in front of is merely out of date, or unusably out of date.
>
>
>> For our own releases we know it because we can do math.
>> So we know that 4.8 is two years old as we currently have 4.12 and it's
>> four
>> releases away. But if one looks at a more global scheme that information
>> is
>> just not there. How old is Firefox 15 or Chrome 12 or Linux 2.6.32? A date
>> based scheme helps there.
>>
>>
> The single number does at least allow you to detect how far out of step
> you are. You can't know how many releases there have been from a mere date.
>

Part of the idea is to have the "update" version in the date version too -
eg 2014.06-1. If we're going to stick with montly updates, it tells you
everything you pointed out plus it adds the date thing, so you know exactly
how old the release is (and you can compare the version with todays date,
which you always know implicitly (moreless)).


> Why is the age of a piece of software interesting? Distributions don't
> necessarily package new releases promptly, and the time elapsed since the
> last release doesn't reveal anything about the importance of the release or
> developer activity.
>

Fwiw, if you tell me you're running 4.11.3, it tells me exactly nothing. If
you tell me you're running 2014.06-2, I can tell you "oh it's september
already, there should be an update for you already".

Cheers
-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140120/6b0eb465/attachment-0001.html>