<table><tr><td style="">ngraham added a comment.
</td></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/T10812#182195" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">T10812#182195</a>, <a href="https://phabricator.kde.org/p/aacid/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@aacid</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Apps that are in the bundle have inconsistent versioning; most use the bundle's own versioning scheme, but others use their own</p></blockquote>
<p>I personally disagree this is a problem. It let's applications hop on and off the release and keep their versioning number intact.</p></div>
</blockquote>
<p>I'm using Dolphin 18.12.3, which comes from KDE Applications 18.12.3. But the bundle it also comes with Okular. Am I using Okular 18.12.3? Or Okular 1.6.3? The promo material says 18.12.3. The version number in my distro's packaging says 18.12.3. Discover, which uses the distro packaging metadata, says 18.12.3. But the <span><span class="phui-tag-view phui-tag-type-shade phui-tag-grey phui-tag-shade "><span class="phui-tag-core ">About Okular</span></span></span> window says 1.6.3. This is confusing and problematic from a user, packager, and promo perspective because it's not clear which version number they should use.</p>
<blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/T10812#182195" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">T10812#182195</a>, <a href="https://phabricator.kde.org/p/aacid/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@aacid</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>The bundle's YY.MM version numbering scheme happens to be the same as Ubuntu's versioning scheme, which causes users to confuse one with another (for example a user with Kubuntu 18.04 is actually using KDE Applications 17.12, not 18.04)</p></blockquote>
<p>I personally disagree this is a problem. Ubuntu didn't invent the YY.MM versioning scheme, on top of that our scheme only overlaps with Ubuntu's 1/3 of the times. Maybe Kubuntu can just put some extra work and make sure that for the .04 release they ship our .04 release if they feel that it confuses their users. Or maybe they could change their versioning scheme.</p></div>
</blockquote>
<p>If you're suggesting that Kubuntu could change their versioning scheme, that's a tacit admission that you do think there's a problem (otherwise there would be no suggestion of a proposed change or solution). It's a problem from a user perspective for just the reason I gave: users confuse our app versions with Ubuntu's own version numbers. "Confused users" is a problem. I agree that it's not a huge issue but I think it <em>is</em> an issue. Maybe it's not worth fixing. But it's an issue.</p>
<blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/T10812#182195" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">T10812#182195</a>, <a href="https://phabricator.kde.org/p/aacid/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@aacid</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>There are no LTS app versions the way there are with Plasma; distros that ship Plasma LTS get stuck with old apps versions that have bugs which have been fixed in later releases</p></blockquote>
<p>I personally disagree this is a problem. If distributions want bug fixes they can either</p>
<ul class="remarkup-list">
<li class="remarkup-list-item">update to a new release</li>
<li class="remarkup-list-item">do the work of doing an LTS branch themselves.</li>
<li class="remarkup-list-item">give us money so we can hire someone to the work for them</li>
</ul></div>
</blockquote>
<p>Updating to a new release isn't an option for the discrete release distros, particular for their LTS releases. Asking them to do an LTS branch themselves or pay us to do it is unreasonable; it's our software and we define our release schedule. All I'm saying is that I think adding LTS versions of apps is something that would be really nice for the discrete release distros that ship our LTS Plasma versions. Right now they can continuously take our LTS Plasma bugfix releases to ensure that the Plasma they ship gets better and better over time, but they can't do this for our apps. This isn't just bad for their users; it's bad for us because we need to handle more time-wasting bugzilla tickets for issues that have already been fixed from people using versions of our software that could be 2 or more years old.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>If this comes from an application developer that wants to maintain 3 branches (LTS, stable, devel) it'd be another thing. Do we know of any developer that would like to maintain such scheme for KDE Applications?</p></blockquote>
<p>I mean, that's what we do for Plasma and it's not a problem. In practice all it means is that when you have a bugfix, instead of landing it on the stable branch and merging to master, you land on the LTS branch, merge to the stable branch, and merge that to master. And in the few cases where it doesn't apply cleanly to the LTS branch, you say, "ehh, too much work, stable or master only" and life goes on. :) It's really not that hard.</p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T10812">https://phabricator.kde.org/T10812</a></div></div><br /><div><strong>To: </strong>ngraham<br /><strong>Cc: </strong>aacid, Yakuake, Okular, Dolphin, Kate, Spectacle, Konsole, Gwenview, KDE PIM, KDE Games, KDE Applications, ngraham<br /></div>