Proposed applications in the release service

[Nate Graham]

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
>>>
>>
>>
> 
>