naming the next major release

[Aaron J. Seigo]

On Tuesday, August 20, 2013 07:06:10 Martin Graesslin wrote:
> 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 :-)

for versioning, i agree.

“Plasma  2” (or whatever) will be a product name, not a version (in the 
technical sense of that word).

thinking about this overnight, i did run into some possible annoyances. we’ve 
been sort of taking this approach with Plasma Active. so now we have Plasma 
Active 4.

i’m unsure how that would work (poorly, i think) with “Plasma 2” as the 
product name.

another approach is to not use a number at all and give it a proper name as we 
did with Plasma Active (which, iirc, was Sebas’ brainchild of a name?). which 
would make the next major version “Plasma <Something>” and this would replace 
Plasma Desktop, Netbook, Active (and perhaps Mediacenter?) as product names. 
they would of course remain buried in the technical details of our code to 
some extent (e.g. there may always be a plasma-mediacenter binary, though it 
would be cool if that went away too ..).

this would reflect even more clearly than my first proposal that we are 
harmonizing all the shells into one Thing(tm).

one tempting idea is to promote “Plasma Active” up as the name used for all 
the workspaces ... 

the most minimalist thing would be to just call it all “Plasma” and be done 
with it and not try at all to differentiate the new release from the old by the 
product name.

another approach would be to shift weight to “Active” and drop “Plasma” from 
the name, though “KDE Active” is  not as google-able and we lose whatever 
value we’ve put into Plasma as a brand.

*sigh* this needs more thought :/

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

i suppose it comes down to the following two things:

* do we feel we can communicate clearly, developer to developer, what Plasma 
is, and how components like KWin fit within that
* do we expect LXDE / Razor developers to be intelligent people who will 
understand technical communication

my experience with both of those things is “yes”

the idea with having a name for this thing we’re making is to give the final 
product a name. consider that if we adopt SDDM as part of that “complete 
product” that SDDM will be part of Plasma (the product), even though SDDM will 
obviously remain an independent project.

this is equally true with all components that are part of the Plasma product.

each component is its own living, breathing thing .. and we pull those 
components together to create an integrated, finished product called Plasma.

it’s the same as a screw that is used to hold together a dining room chair. it 
can also be used to hang a picture on a wall. even though it is part of the 
“chair” product, it can be used for other purposes as well.

that is what we need to communicate clearly to projects such as LXDE / Razor.

it’s also mindset i’m hoping people working on various components that make up 
Plasma will adopt as it accurately captures how we work together 
collaboratively yet with independence. 

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

we already get bug reports for kdelibs and Qt and all sorts of other things. 
this is, i’m afraid, unavoidable.

-- 
Aaron J. Seigo
-------------- 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/d62eb61a/attachment-0001.sig>