naming the next major release

[Martin Graesslin]

On Monday 19 August 2013 21:56:35 Aaron J. Seigo wrote:
> 3. ‘2’ ... why “two” if this is version 5? well, libplasma is actually going
> to be version 6 iirc, so it isn’t the library. i also am not a big believer
> in branding after version numbers. neither are any of our proprietary
> competitors who have a lot more marketing and communications savvy than we
> tend to. ;) what i like about 2 is:
> 
> * it communicates this is something after the first. it’s that whole “two
> point oh” thing, though hopefully less hype than, say, “web 2.0” ;)
> 
> * it’s simple and direct
> 
> * ‘2’ is a couple, and a couple is a nice human idea :) this is borne out by
> the “1, 2, many” pattern in many ancient languages. we know 1, we know 2,
> after that it’s just an abstract concept.
I would like to get rid of version numbers in the traditional way. If the 
numbers are small, it's fine. But looking at many projects I am not able to get 
how old software is based on the number.

So instead I suggest that we go by year and numbering:
* 2014.1.4
* 2014.2.2
* 2014.3.1
-> year.major.minor

It would also prevent the confusion that several parts of our software has now 
different versions and especially that 4+1=2 :-)
> 
> 
> 
> Sooooooooooo ... here is my proposal:
> 
> 	We call it Plasma 2 and use that as a rallying call to
> 	focus on its unified user experience
> 	across the spectrum of devices people use today.
I do want to promote KWin for the usage in LXDE/Razor as in the next version 
we will hardly have any build-time dependencies from frameworks higher than 
tier1. I'm concerned that a generic name "Plasma" would work against that as 
it would be difficult to communicate that although being part of Plasma not 
being part of Plasma. If someone has a good idea on how to properly 
communicate this without being confusing (especially for users who want the 
lightweight aspect of LXDE and Plasma is for people in that user group 
unfortunately the definition of bloat) I consider this as a non-blocking issue 
for the naming.

We should also think about what the name would mean for bug reporting. We 
don't want that all bugs for everything what is in kde-workspaces nowadays 
ends up in the component plasma.

Cheers
Martin

P.S. Thanks for bringing the topic to the mailing list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130820/60dbd7cc/attachment.sig>