naming the next major release

[Aaron J. Seigo]

On Monday, August 19, 2013 23:08:15 Marco Martin wrote:
> On Monday 19 August 2013, Kevin Ottens 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.
> > 
> > Not that its relevant for the rest of the discussion, but as the library
> > number itself is concerned you can make it 5. And that's in fact my
> > preference as I'd like all our library numbers to be in sync for a change.
..
> yes, plasma2 has .so.5 atm, plasma1 is 4

Really? I’m getting this from master:

-- Installing: /opt/kde4/lib/libplasma.so.3.0.0

That’s also what I see in the openSuse packages.

So, yes, I got the # wrong .. it’s 3, not 5 currently .. so we’d end up with 4 
unless we skip it go to 5. Still, the “number used in the name doesn’t match 
the version number of <insert component here>” comment remains

It’s also made more complex once we look at things like kscreen which seems to 
be at version 1.x; the more components we look at as part of the Plasma shell 
the more version variance there is. 

If we do end up using SDDM then it gets even more difficult as we don’t even 
control the versioning of all the software.

Basically, I’m suggesting that naming the product after the version of the 
software isn’t a necessity and may not even be possible unless we elevate one 
specific component to be the “defining” component, which I don’t think we ought 
to do.

-- 
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/e5c96f27/attachment.sig>