[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Proposed applications in the release service
From:       Nate Graham <nate () kde ! org>
Date:       2020-10-13 1:55:29
Message-ID: 4ae38564-36e7-f08a-ae2f-d1dc112195a4 () kde ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]