You don't have to; it's optional. However I personally recommend it
because otherwise you need to mentally map the version number displayed
in the UI to the version number used in CMake, the git repo branches,
bug tracker, the tarballs, and so on. In the end I think it's simpler to
just have the app use the release service's version numbering scheme.
Speaking personally, I like it when the version numbers are standardized
because this makes it simple for me to predict the next version that a
fix will make into for purposes of writing the weekly blog post. :) I
also like how the release service's version number has a date built in,
which gives it semantic meaning. You can tell exactly how old a version
is just from its number.
Nate
On 10/12/20 6:32 PM, Andrius Štikonas wrote:
I think yy.mm versioning numbers are requirement in the release service anyway,
but
in any case I wouldn't mind changing it (just not for upcoming release this
Friday).
Andrius
2020 m. spalio 13 d., antradienis 01:28:08 BST Nate Graham rašė:
+1 from me, obviously :)
I would also recommend changing the version numbering of these apps to
use the release service's own versioning scheme (i.e.
YY.MM.minorversion) to avoid making users, packagers, bug triagers, and
developers have to juggle multiple version numbers in their brains. :)
Nate
On 10/12/20 2:52 PM, Andrius Štikonas wrote:
Hi,
A week ago Nate Graham suggested that I move KDE Partition Manager and KPMcore
to the release service.
(After the upcoming 4.2.0 release which will be released this Friday)
Would there be any objections to this?
I would also like to propose moving KTorrent and Libktorrent there. At the
moment libktorrent is a dependency
of KGet which is already in the monthly release service.
Kind regards,
Andrius
