Re: PIM: Version alignment
El dilluns, 19 de setembre de 2016, a les 0:08:30 CEST, Ingo Klöcker va escriure: > Moreover, I agree that it's confusing for potential contributors that > the tags in the repositories do not match the version numbers. This > should be fixed by creating tags matching the version numbers > additionally to the KDE_Applications_YY.MM tags. IMO that's also part of > the maintainers' job for all applications that are part of the KDE > Applications release, but that do not share the KDE Applications version > number. > > Last, but not least, all applications that are part of the KDE > Applications release should define their version in a standardized way, > so that it can be extracted automatically to update Bugzilla and maybe > also to set the additional version tag. Yes, this would be nice, also by doing this, the tagging scripts can also do the paragraph above without further human intervention if that's what we want. Now, would someone volunteer to define such a scheme in a way it's usable by everyone? Cheers, Albert signature.asc Description: This is a digitally signed message part.
Re: PIM: Version alignment
On Mon, September 19, 2016 8:38 am, denis.k...@posteo.de wrote: >> On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: >>> From their perspective their distribution shipped them Applications >>> 15.10 (as that will be what the release notes say) yet when they got >>> to report a bug they won't find those version numbers. >> >> This argument is flawed. It ignores that a lot of KDE applications... > > No, it's not. Applications that are not released as part of the KDE > Applications are not mentioned in the release notes of KDE Applications > [1], where only one version is clearly stated for all applications in > the list. > >> If a user is confused about the version of a specific application, >> then... > > What about developers being confused? For example, dvratil puts tags in > commit messages like "FIXED-IN: 16.08.1" (see 364994, 356747, 291474, > 340813, 367075, 364342, ...). In contrast, montel uses internal versions > in these tags. I've never found a problem in bug reports arising from using a separate application version. The version related problems in bug reports are usually trying to establish which Frameworks version, which desktop, desktop version and distro version the user has installed. > Am 16.09.2016 21:55 schrieb David Jarvie: >> The KDE Applications version is simply a date indication. It's very >> useful, for developers who want it, to be able to have an individual >> application version which has a meaning in functional terms. > > This is only a valid point for projects where versions mean anything. > For KDE PIM, the current versioning scheme is 5.A.B as released as part > of kde-apps-x.y.z, where A is the number of times "x.y" changed since > 15.12, any B = z. So, it can be directly mapped to kde-apps versions if > you know how, but does not convey any other information than that. As far as I'm concerned, it should be up to each application's maintainer whether to use the KDE Applications version number or their own version. In the latter case, the version can mean whatever they find useful. KDE is not a monolithic piece of software, and it shouldn't try to behave like one by forcing individual applications to adopt what is essentially an arbitrary version number which has no relationship to the application's development status. The KDE Applications release is just a convenient bundling of a bunch of Frameworks based applications in various stages of development - some might have major feature changes, while others might have just the odd bugfix, and some might be unchanged since the last KDE Applications release. In the end, I regard this as a (small) issue of freedom. Yes, applications need to comply with some basic KDE standards if they are to be part of KDE Applications, but this is taking central diktat a step too far. > In case the separate versioning scheme is here to stay: +1 for adding > git tags for internal versions as well, which makes it easier for > contributors. Alternatively, list versions in bugzilla as in the > umbrello project, like "2.20.1 (KDE Applications 16.08.1)", which makes > it easier for contributors AND users. That seems a good idea. Adoption of a standard way of setting the application's version would then, in theory at least, enable Bugzilla to be scripted to add new release versions in that format. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: PIM: Version alignment
On Mon, Sep 19, 2016 at 10:08 AM, Ingo Klöcker wrote: > On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: >> From their perspective their distribution shipped them Applications >> 15.10 (as that will be what the release notes say) yet when they got >> to report a bug they won't find those version numbers. > > This argument is flawed. It ignores that a lot of KDE applications > (actually most KDE applications) are not released as part of a KDE > Applications release. Obviously, none of these KDE applications shares > the version number of the KDE Applications release. Are the users > confused about the versions of those applications, too? Anything outside the KDE Applications release module is not relevant here - these applications will have separate release announcements which will contain the appropriate version numbers. > > Taking your argument one step further: Any application released with > Ubuntu 16.04 (to name a random example) should share the same version > number because otherwise users could be confused if they wanted to > report a bug in an application shipped with Ubuntu 16.04. I hope that > the absurdity of this proposal is obvious. The version numbers used by our distributors are not relevant - most release notes will state which version of KDE software they're delivering. > > If a user is confused about the version of a specific application, then > a simple check of Help->About (or an --version on the > command line) will clarify the version. > > And if Help->Report Bug does not automatically set the correct version, > then the application's maintainer is not doing his/her job properly (or > the Report Bug functionality or Bugzilla is broken). Considering this is the case for numerous PIM components (KMail, Kontact, KOrganizer, Akregator, Akonadi and others) i'm considering PIM as an entire group to have collectively disregarded their responsibilities as maintainers. More than suitable justification for having your version numbers harmonized from my perspective. > > Moreover, I agree that it's confusing for potential contributors that > the tags in the repositories do not match the version numbers. This > should be fixed by creating tags matching the version numbers > additionally to the KDE_Applications_YY.MM tags. IMO that's also part of > the maintainers' job for all applications that are part of the KDE > Applications release, but that do not share the KDE Applications version > number. > > Last, but not least, all applications that are part of the KDE > Applications release should define their version in a standardized way, > so that it can be extracted automatically to update Bugzilla and maybe > also to set the additional version tag. > > >> Also, these >> versions have already been added on Bugzilla, so the confusion is >> present amongst our own developers as well. > > The version numbers in Bugzilla can be fixed easily. Even for long > released applications. > > >> From my perspective, this discord should be eliminated by harmonizing >> the version numbers. > > A partial harmonization of the version numbers (because you cannot > harmonize the version numbers of all KDE applications) won't fix > anything. > > > Regards, > Ingo Regards, Ben
Re: PIM: Version alignment
The lack of the usual help menu in Kontact is an exception compared to all other applications, and a regression from the older versions (read: bug). Let's file it against 5.3.1 and see if it will be fixed in 16.12.0 ;-) Am 19.09.2016 10:08 schrieb Luigi Toscano: Il 19 settembre 2016 09:38:14 CEST, denis.k...@posteo.de ha scritto: On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: If a user is confused about the version of a specific application, then a simple check of Help->About (or an --version on the command line) will clarify the version. Kontact does not have this menu item, just "Introduction to ". Although the version number is displayed there, that's not really obvious. As a long term user of KDE PIM, I would probably not click on any buttons labelled "Introduction...", whether I'm looking for a version number or not. CLI skills should not be required for someone to report a bug. The lack of the usual help menu in Kontact is an exception compared to all other applications, and a regression from the older versions (read: bug).
Re: PIM: Version alignment
Il 19 settembre 2016 09:38:14 CEST, denis.k...@posteo.de ha scritto: >> On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: >> If a user is confused about the version of a specific application, >then >> a simple check of Help->About (or an --version on >the >> command line) will clarify the version. > >Kontact does not have this menu item, just "Introduction to name>". >Although the version number is displayed there, that's not really >obvious. As a long term user of KDE PIM, I would probably not click on >any buttons labelled "Introduction...", whether I'm looking for a >version number or not. CLI skills should not be required for someone to > >report a bug. The lack of the usual help menu in Kontact is an exception compared to all other applications, and a regression from the older versions (read: bug). -- Luigi
Re: PIM: Version alignment
On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: From their perspective their distribution shipped them Applications 15.10 (as that will be what the release notes say) yet when they got to report a bug they won't find those version numbers. This argument is flawed. It ignores that a lot of KDE applications... No, it's not. Applications that are not released as part of the KDE Applications are not mentioned in the release notes of KDE Applications [1], where only one version is clearly stated for all applications in the list. If a user is confused about the version of a specific application, then... What about developers being confused? For example, dvratil puts tags in commit messages like "FIXED-IN: 16.08.1" (see 364994, 356747, 291474, 340813, 367075, 364342, ...). In contrast, montel uses internal versions in these tags. If a user is confused about the version of a specific application, then a simple check of Help->About (or an --version on the command line) will clarify the version. Kontact does not have this menu item, just "Introduction to ". Although the version number is displayed there, that's not really obvious. As a long term user of KDE PIM, I would probably not click on any buttons labelled "Introduction...", whether I'm looking for a version number or not. CLI skills should not be required for someone to report a bug. Besides, my prefered method to check the version of an installed package is "eix -ec " (gentoo specific), which at the moment yields "... kde-apps/kmail (16.08.1 (5)...". Am 16.09.2016 21:55 schrieb David Jarvie: The KDE Applications version is simply a date indication. It's very useful, for developers who want it, to be able to have an individual application version which has a meaning in functional terms. This is only a valid point for projects where versions mean anything. For KDE PIM, the current versioning scheme is 5.A.B as released as part of kde-apps-x.y.z, where A is the number of times "x.y" changed since 15.12, any B = z. So, it can be directly mapped to kde-apps versions if you know how, but does not convey any other information than that. Moreover, I agree that it's confusing for potential contributors that the tags in the repositories do not match the version numbers. This should be fixed by creating tags matching the version numbers additionally to the KDE_Applications_YY.MM tags. IMO that's also part of the maintainers' job for all applications that are part of the KDE Applications release, but that do not share the KDE Applications version number. In case the separate versioning scheme is here to stay: +1 for adding git tags for internal versions as well, which makes it easier for contributors. Alternatively, list versions in bugzilla as in the umbrello project, like "2.20.1 (KDE Applications 16.08.1)", which makes it easier for contributors AND users. Regards, Denis [1] https://www.kde.org/announcements/fulllog_applications.php?version=16.08.0
Re: PIM: Version alignment
On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: > From their perspective their distribution shipped them Applications > 15.10 (as that will be what the release notes say) yet when they got > to report a bug they won't find those version numbers. This argument is flawed. It ignores that a lot of KDE applications (actually most KDE applications) are not released as part of a KDE Applications release. Obviously, none of these KDE applications shares the version number of the KDE Applications release. Are the users confused about the versions of those applications, too? Taking your argument one step further: Any application released with Ubuntu 16.04 (to name a random example) should share the same version number because otherwise users could be confused if they wanted to report a bug in an application shipped with Ubuntu 16.04. I hope that the absurdity of this proposal is obvious. If a user is confused about the version of a specific application, then a simple check of Help->About (or an --version on the command line) will clarify the version. And if Help->Report Bug does not automatically set the correct version, then the application's maintainer is not doing his/her job properly (or the Report Bug functionality or Bugzilla is broken). Moreover, I agree that it's confusing for potential contributors that the tags in the repositories do not match the version numbers. This should be fixed by creating tags matching the version numbers additionally to the KDE_Applications_YY.MM tags. IMO that's also part of the maintainers' job for all applications that are part of the KDE Applications release, but that do not share the KDE Applications version number. Last, but not least, all applications that are part of the KDE Applications release should define their version in a standardized way, so that it can be extracted automatically to update Bugzilla and maybe also to set the additional version tag. > Also, these > versions have already been added on Bugzilla, so the confusion is > present amongst our own developers as well. The version numbers in Bugzilla can be fixed easily. Even for long released applications. > From my perspective, this discord should be eliminated by harmonizing > the version numbers. A partial harmonization of the version numbers (because you cannot harmonize the version numbers of all KDE applications) won't fix anything. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: PIM: Version alignment
On Sat, Sep 17, 2016 at 6:09 PM, laurent Montel wrote: > Le vendredi 16 septembre 2016, 20:55:16 CEST David Jarvie a écrit : >> On 16 September 2016 11:55:50 BST, Jonathan Riddell >> wrote: >> >On Fri, Sep 16, 2016 at 10:52:32PM +1200, Ben Cooksley wrote: >> >> It seems that KDE PIM, despite being part of the Applications >> > >> >release, >> > >> >> doesn't align it's internal version numbers with the rest of the >> >> Applications release. >> >> >> >> This causes issues - as we've received complaints about various >> >> products (all being PIM products) missing versions on bugs.kde.org, >> >> due to this mismatch. It's also confusing for users. >> >> >> >> Can PIM please fall in line with the rest of Applications? >> > >> >This is common across lots of apps in Applications. e.g. Umbrello is >> >at 2.20.99 internally. It's always been the case. >> > >> >Jonathan >> >> This idea was discussed a year or two ago, and it was agreed then that >> applications would keep their own version numbering, if desired. >> >> The KDE Applications version is simply a date indication. It's very useful, >> for developers who want it, to be able to have an individual application >> version which has a meaning in functional terms. >> >> I strongly disagree with this proposal to change version numbers. > > I disagree too to change version number. > I don't want to define version again 16.08.x for developping version I will > not > change 16.08.54 for example. > We need when we look at version that kmail 5.3.x is based on kf5 etc as kdepim > 4.11.x was kde4 version. > > When I look at version in okteta for example it's 0.20.60, kigo is 0.5.6 > => so nobody use harmonized version and it's seem to be not a problem. > > So I want to continue to use existing version as previous. > > When I look at in bugs.kde.org version for kmail2 there is not a 16.x version > or 5.3.x version. > So it's not a problem about version in kmail but a missing version in > bugzilla. Please note that kmail2 is just one product. As for why versions are absent, that is because no developer requested or created them when they bumped the versions in preparation for release... As for the confusion which everyone here is dismissing - please see https://bugs.kde.org/show_bug.cgi?id=335654#c7 > > Regards. > >> >> -- >> David Jarvie >> KAlarm author, KDE developer >> http://www.astrojar.org.uk/kalarm > > > -- > Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr > > Regards, Ben
Re: PIM: Version alignment
Le vendredi 16 septembre 2016, 20:55:16 CEST David Jarvie a écrit : > On 16 September 2016 11:55:50 BST, Jonathan Riddell wrote: > >On Fri, Sep 16, 2016 at 10:52:32PM +1200, Ben Cooksley wrote: > >> It seems that KDE PIM, despite being part of the Applications > > > >release, > > > >> doesn't align it's internal version numbers with the rest of the > >> Applications release. > >> > >> This causes issues - as we've received complaints about various > >> products (all being PIM products) missing versions on bugs.kde.org, > >> due to this mismatch. It's also confusing for users. > >> > >> Can PIM please fall in line with the rest of Applications? > > > >This is common across lots of apps in Applications. e.g. Umbrello is > >at 2.20.99 internally. It's always been the case. > > > >Jonathan > > This idea was discussed a year or two ago, and it was agreed then that > applications would keep their own version numbering, if desired. > > The KDE Applications version is simply a date indication. It's very useful, > for developers who want it, to be able to have an individual application > version which has a meaning in functional terms. > > I strongly disagree with this proposal to change version numbers. I disagree too to change version number. I don't want to define version again 16.08.x for developping version I will not change 16.08.54 for example. We need when we look at version that kmail 5.3.x is based on kf5 etc as kdepim 4.11.x was kde4 version. When I look at version in okteta for example it's 0.20.60, kigo is 0.5.6 => so nobody use harmonized version and it's seem to be not a problem. So I want to continue to use existing version as previous. When I look at in bugs.kde.org version for kmail2 there is not a 16.x version or 5.3.x version. So it's not a problem about version in kmail but a missing version in bugzilla. Regards. > > -- > David Jarvie > KAlarm author, KDE developer > http://www.astrojar.org.uk/kalarm -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: PIM: Version alignment
On Sat, Sep 17, 2016 at 7:55 AM, David Jarvie wrote: > > > On 16 September 2016 11:55:50 BST, Jonathan Riddell wrote: >> >> On Fri, Sep 16, 2016 at 10:52:32PM +1200, Ben Cooksley wrote: >>> >>> It seems that KDE PIM, despite being part of the Applications release, >>> doesn't align it's internal version numbers with the rest of the >>> Applications release. >>> >>> This causes issues - as we've received complaints about various >>> products (all being PIM products) missing versions on bugs.kde.org, >>> due to this mismatch. It's also confusing for users. >>> >>> Can PIM please fall in line with the rest of Applications? >> >> >> This is common across lots of apps in Applications. e.g. Umbrello is at >> 2.20.99 internally. It's always been the case. >> >> Jonathan >> > > This idea was discussed a year or two ago, and it was agreed then that > applications would keep their own version numbering, if desired. > > The KDE Applications version is simply a date indication. It's very useful, > for developers who want it, to be able to have an individual application > version which has a meaning in functional terms. > > I strongly disagree with this proposal to change version numbers. Unfortunately all it leads to is user confusion as to what they've actually installed. >From their perspective their distribution shipped them Applications 15.10 (as that will be what the release notes say) yet when they got to report a bug they won't find those version numbers. Also, these versions have already been added on Bugzilla, so the confusion is present amongst our own developers as well. >From my perspective, this discord should be eliminated by harmonizing the version numbers. > > -- > David Jarvie > KAlarm author, KDE developer > http://www.astrojar.org.uk/kalarm Regards, Ben
Re: PIM: Version alignment
On Sat, Sep 17, 2016 at 12:09 AM, Luigi Toscano wrote: > On Saturday, 17 September 2016 00:01:59 CEST Ben Cooksley wrote: >> On Fri, Sep 16, 2016 at 11:10 PM, Luigi Toscano >> >> wrote: >> > On Friday, 16 September 2016 23:04:38 CEST Ben Cooksley wrote: >> >> On Fri, Sep 16, 2016 at 10:55 PM, Luigi Toscano >> >> >> >> wrote: >> >> > On Friday, 16 September 2016 22:52:32 CEST Ben Cooksley wrote: >> >> >> Hi all, >> >> >> >> >> >> It seems that KDE PIM, despite being part of the Applications release, >> >> >> doesn't align it's internal version numbers with the rest of the >> >> >> Applications release. >> >> >> >> >> >> This causes issues - as we've received complaints about various >> >> >> products (all being PIM products) missing versions on bugs.kde.org, >> >> >> due to this mismatch. It's also confusing for users. >> >> >> >> >> >> Can PIM please fall in line with the rest of Applications? >> >> > >> >> > I don't think this is required: many pieces of Applications uses a >> >> > different internal version. I'd really like to have this not enforced. >> >> >> >> I'd like to see it enforced. >> >> See https://bugs.kde.org/show_bug.cgi?id=335654#c7 for the confusion >> >> created (and Sysadmin effort taken). >> > >> > I understand it takes effort, but I strongly disagree with the enforcing. >> > >> >> It also means that the process of releasing applications can't be >> >> automated to create all the necessary versions, so someone has to do >> >> it manually. >> >> And chances are, it ain't going to be the application maintainer. >> > >> > The versions are defined in each repository; they can be extracted (by the >> > CI, by some other script) and compared with the list of available version >> > for each component. I.e. it can be automated even with different internal >> > versions. >> How would you version the tags in such a misaligned world? >> At the moment it's very confusing as to what the version is - what the >> Application says it is or what the general release umbrella says it >> is. > > I don't see how it affects the tag. The tag is the global one for > Applications, the internal version > --version or the about info shows the version. > > >> >> For that reason i'd very much like to see it harmonized. > > The problem here is to have an easy way to update the version data on > bugzilla. I think that this can be automated. Considering in some cases applications don't set it from CMake but from a header or cpp file, i'd be wary of saying this can be automated. It could be automated fairly easily (using Riddell's code and a list of appropriate products) if PIM projects all followed the same universal version numbers. > > -- > Luigi Regards, Ben
Re: PIM: Version alignment
On 16 September 2016 11:55:50 BST, Jonathan Riddell wrote: >On Fri, Sep 16, 2016 at 10:52:32PM +1200, Ben Cooksley wrote: >> It seems that KDE PIM, despite being part of the Applications >release, >> doesn't align it's internal version numbers with the rest of the >> Applications release. >> >> This causes issues - as we've received complaints about various >> products (all being PIM products) missing versions on bugs.kde.org, >> due to this mismatch. It's also confusing for users. >> >> Can PIM please fall in line with the rest of Applications? > >This is common across lots of apps in Applications. e.g. Umbrello is >at 2.20.99 internally. It's always been the case. > >Jonathan This idea was discussed a year or two ago, and it was agreed then that applications would keep their own version numbering, if desired. The KDE Applications version is simply a date indication. It's very useful, for developers who want it, to be able to have an individual application version which has a meaning in functional terms. I strongly disagree with this proposal to change version numbers. -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: PIM: Version alignment
> The problem here is to have an easy way to update the version data on > bugzilla. I think that this can be automated. Not trivial that due to bugzilla not having an API and the bugzilla Product names being unrelated to any git repository. The script I use for Plasma uses CURL and a local saved cookie and a manually created list of Products and a manually set version to update the versions https://quickgit.kde.org/?p=releaseme.git&a=blob&h=43677ec55cea4b755176ce11c2b9e89ca2cfa56f&hb=dea69ae3b6ec27266c09e60d11e52b80b3c79e96&f=plasma%2Fplasma-add-bugzilla-versions it could be automated a bit more by having a standard cmake or other known variable in git repos listing the bugzilla versions and the application version. But that's quite a lot of manual work to set up. Jonathan
Re: PIM: Version alignment
On Saturday, 17 September 2016 00:01:59 CEST Ben Cooksley wrote: > On Fri, Sep 16, 2016 at 11:10 PM, Luigi Toscano > > wrote: > > On Friday, 16 September 2016 23:04:38 CEST Ben Cooksley wrote: > >> On Fri, Sep 16, 2016 at 10:55 PM, Luigi Toscano > >> > >> wrote: > >> > On Friday, 16 September 2016 22:52:32 CEST Ben Cooksley wrote: > >> >> Hi all, > >> >> > >> >> It seems that KDE PIM, despite being part of the Applications release, > >> >> doesn't align it's internal version numbers with the rest of the > >> >> Applications release. > >> >> > >> >> This causes issues - as we've received complaints about various > >> >> products (all being PIM products) missing versions on bugs.kde.org, > >> >> due to this mismatch. It's also confusing for users. > >> >> > >> >> Can PIM please fall in line with the rest of Applications? > >> > > >> > I don't think this is required: many pieces of Applications uses a > >> > different internal version. I'd really like to have this not enforced. > >> > >> I'd like to see it enforced. > >> See https://bugs.kde.org/show_bug.cgi?id=335654#c7 for the confusion > >> created (and Sysadmin effort taken). > > > > I understand it takes effort, but I strongly disagree with the enforcing. > > > >> It also means that the process of releasing applications can't be > >> automated to create all the necessary versions, so someone has to do > >> it manually. > >> And chances are, it ain't going to be the application maintainer. > > > > The versions are defined in each repository; they can be extracted (by the > > CI, by some other script) and compared with the list of available version > > for each component. I.e. it can be automated even with different internal > > versions. > How would you version the tags in such a misaligned world? > At the moment it's very confusing as to what the version is - what the > Application says it is or what the general release umbrella says it > is. I don't see how it affects the tag. The tag is the global one for Applications, the internal version --version or the about info shows the version. > > For that reason i'd very much like to see it harmonized. The problem here is to have an easy way to update the version data on bugzilla. I think that this can be automated. -- Luigi
Re: PIM: Version alignment
On Fri, Sep 16, 2016 at 11:10 PM, Luigi Toscano wrote: > On Friday, 16 September 2016 23:04:38 CEST Ben Cooksley wrote: >> On Fri, Sep 16, 2016 at 10:55 PM, Luigi Toscano >> >> wrote: >> > On Friday, 16 September 2016 22:52:32 CEST Ben Cooksley wrote: >> >> Hi all, >> >> >> >> It seems that KDE PIM, despite being part of the Applications release, >> >> doesn't align it's internal version numbers with the rest of the >> >> Applications release. >> >> >> >> This causes issues - as we've received complaints about various >> >> products (all being PIM products) missing versions on bugs.kde.org, >> >> due to this mismatch. It's also confusing for users. >> >> >> >> Can PIM please fall in line with the rest of Applications? >> > >> > I don't think this is required: many pieces of Applications uses a >> > different internal version. I'd really like to have this not enforced. >> >> I'd like to see it enforced. >> See https://bugs.kde.org/show_bug.cgi?id=335654#c7 for the confusion >> created (and Sysadmin effort taken). > > I understand it takes effort, but I strongly disagree with the enforcing. > >> >> It also means that the process of releasing applications can't be >> automated to create all the necessary versions, so someone has to do >> it manually. >> And chances are, it ain't going to be the application maintainer. > > The versions are defined in each repository; they can be extracted (by the CI, > by some other script) and compared with the list of available version for each > component. I.e. it can be automated even with different internal versions. How would you version the tags in such a misaligned world? At the moment it's very confusing as to what the version is - what the Application says it is or what the general release umbrella says it is. For that reason i'd very much like to see it harmonized. > > -- > Luigi Regards, Ben
Re: PIM: Version alignment
On Friday, 16 September 2016 23:04:38 CEST Ben Cooksley wrote: > On Fri, Sep 16, 2016 at 10:55 PM, Luigi Toscano > > wrote: > > On Friday, 16 September 2016 22:52:32 CEST Ben Cooksley wrote: > >> Hi all, > >> > >> It seems that KDE PIM, despite being part of the Applications release, > >> doesn't align it's internal version numbers with the rest of the > >> Applications release. > >> > >> This causes issues - as we've received complaints about various > >> products (all being PIM products) missing versions on bugs.kde.org, > >> due to this mismatch. It's also confusing for users. > >> > >> Can PIM please fall in line with the rest of Applications? > > > > I don't think this is required: many pieces of Applications uses a > > different internal version. I'd really like to have this not enforced. > > I'd like to see it enforced. > See https://bugs.kde.org/show_bug.cgi?id=335654#c7 for the confusion > created (and Sysadmin effort taken). I understand it takes effort, but I strongly disagree with the enforcing. > > It also means that the process of releasing applications can't be > automated to create all the necessary versions, so someone has to do > it manually. > And chances are, it ain't going to be the application maintainer. The versions are defined in each repository; they can be extracted (by the CI, by some other script) and compared with the list of available version for each component. I.e. it can be automated even with different internal versions. -- Luigi
Re: PIM: Version alignment
On Fri, Sep 16, 2016 at 10:55 PM, Luigi Toscano wrote: > On Friday, 16 September 2016 22:52:32 CEST Ben Cooksley wrote: >> Hi all, >> >> It seems that KDE PIM, despite being part of the Applications release, >> doesn't align it's internal version numbers with the rest of the >> Applications release. >> >> This causes issues - as we've received complaints about various >> products (all being PIM products) missing versions on bugs.kde.org, >> due to this mismatch. It's also confusing for users. >> >> Can PIM please fall in line with the rest of Applications? > > I don't think this is required: many pieces of Applications uses a different > internal version. I'd really like to have this not enforced. I'd like to see it enforced. See https://bugs.kde.org/show_bug.cgi?id=335654#c7 for the confusion created (and Sysadmin effort taken). It also means that the process of releasing applications can't be automated to create all the necessary versions, so someone has to do it manually. And chances are, it ain't going to be the application maintainer. > > Ciao > -- > Luigi > Regards, Ben
Re: PIM: Version alignment
On Friday, 16 September 2016 22:52:32 CEST Ben Cooksley wrote: > Hi all, > > It seems that KDE PIM, despite being part of the Applications release, > doesn't align it's internal version numbers with the rest of the > Applications release. > > This causes issues - as we've received complaints about various > products (all being PIM products) missing versions on bugs.kde.org, > due to this mismatch. It's also confusing for users. > > Can PIM please fall in line with the rest of Applications? I don't think this is required: many pieces of Applications uses a different internal version. I'd really like to have this not enforced. Ciao -- Luigi
Re: PIM: Version alignment
On Fri, Sep 16, 2016 at 10:52:32PM +1200, Ben Cooksley wrote: > It seems that KDE PIM, despite being part of the Applications release, > doesn't align it's internal version numbers with the rest of the > Applications release. > > This causes issues - as we've received complaints about various > products (all being PIM products) missing versions on bugs.kde.org, > due to this mismatch. It's also confusing for users. > > Can PIM please fall in line with the rest of Applications? This is common across lots of apps in Applications. e.g. Umbrello is at 2.20.99 internally. It's always been the case. Jonathan
PIM: Version alignment
Hi all, It seems that KDE PIM, despite being part of the Applications release, doesn't align it's internal version numbers with the rest of the Applications release. This causes issues - as we've received complaints about various products (all being PIM products) missing versions on bugs.kde.org, due to this mismatch. It's also confusing for users. Can PIM please fall in line with the rest of Applications? Regards, Ben
