[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