[kde-promo] The name of Applications 4.14 + 1 - how about splitting into 4-part and 5-part

Aaron J. Seigo aseigo at kde.org
Fri Jul 18 09:28:38 UTC 2014


On Friday, July 18, 2014 10:53:04 Cornelius Schumacher wrote:
> We have different audiences, which need different messages. For a packager
> the version number communicates something different than for a user. A
> developer expresses something different with a version number than a promo
> person.

Since these aren't libraries, I think we can assume the primary audience is 
users. Version numbers on the individual applications will still be there for 
packagers, and we tend to communicate with packagers no via press releases by 
on the mailing lists, irc and blogs.

Still, we need to consider how it gets presented to the user (as "the 
audience"), as you note. I imagine that many people will see "KDE Applications 
2014.07" and run to their package managers looking for packages with "2014.07" 
on them. Perhaps we need to communicate in those releases that included 
applications have their own version numbers even though they are released at 
the same *time*.

This is already the case for our users with the various applications suites 
and extragear applications. They may have "KDE 4.12" (to use the wrong 
terminology on purpose here :), but they have Amarok <something totally 
different>. So there is precedence for this, but if we move ALL of the 
applications to this model while keeping a single release date we need to 
communicate that *clearly*.

Perhaps we can direct packagers to note in the package descriptions the 
release date-version? (I'm not a packager, so I don't know if that makes any 
sense... )

This also opens the gateway for applications not previously part of the SC to 
take part in the timed releases.

In the more immediate issue of Platform 4 versus Frameworks 5.x applications 
being in one lump, it ought to be enough in the release to note that as we are 
in version transition some applications build against Platform 4 and some 
against Frameworks 5, though in future releases they will eventually all use 
Frameworks 5. In the release notes we can make a list of which are which.

The *nice* thing about releasing them all together is that not only is it 
probably less work for the release team, but it creates continuity for users 
and packagers (newly ported applications aren't migrating from a Platform 4 to 
a Frameworks 5 bundle in each release; they are always in the same place just 
with new deps). It will also emphasize the independence of KDE's libraries 
both from each other (4 vs 5) as well as the applications themselves; one can 
have both sets of libraries installed (regardless of whether they use Plasma 4 
or Plasma 5 or something entirely different) and get all the apps .. it doesn't 
matter.

If we separate them into two sets of applications, we may end up 
creating/reinforcing an artificial distinction that you can only have one OR 
the other, but probably not both. If we wish to encourage co-installation of 
Platform 4 and Frameworks 5 libraries, which I imagine we do, then a single 
bundle may help in communicating that.

> If we don't get clarity about what we communicate to whom, and make sure
> that how we use version numbers fits into this, we will confuse people.

+1

-- 
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/release-team/attachments/20140718/64ab5590/attachment-0001.sig>


More information about the release-team mailing list