Re: Application version numbers, SC version numbers and FIXED-IN
Le Thursday 27 December 2012 16:16:55 Allen Winter a écrit : We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Oh. I remember KMail1 used a 1.something version number, am I wrong? I guess you changed it with KMail2. Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. That sounds too complicated and easy to get wrong. The easiest solution is probably for Gwenview 2.10.0 to become 4.10.0. Any objection to me bumping the version before 4.10rc2 tagging freeze? Aurélien ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
On Friday, December 28, 2012 00:48:51 Albert Astals Cid wrote: We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. Which means someone needs to do a lot of work (lot of work, getting all the new and old versions for more than 100 repos and then running the script and then putting it somewhere in the web) Coding the script is the easy part, finding someone to run and maintain it is the hard part. Of course the great part would be having this run automagically. I guess I was assuming we were already feeding the query output into a separate script already to generate the changelog. As a practical measure I agree with using the KDE SC version for FIXED-IN (which is what I do with JuK, when I work on it), I was more pointing out that the query from Bugzilla is already not the primary source for this particular data (so much as fat-fingering the FIXED-IN line in the commit will drop it from the changelog). Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Application version numbers, SC version numbers and FIXED-IN
Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. Is there an established policy for this? Should we use KDE SC version numbers in the FIXED-IN field? Aurélien ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, e.g https://bugs.kde.org/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=RESOLVEDbug_status=VERIFIEDbug_status=CLOSEDemailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=2011-06-01chfieldto=Nowchfield=cf_versionfixedinchfieldvalue=4.9.4cmdtype=doitorder=Bug+Numberfield0-0-0=nooptype0-0-0=noopvalue0-0-0= You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. Cheers, Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday, December 27, 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. There's an existing script which figures out how to generate a changelog from the old XML based on a version number which would probably be easy to adapt (and I'd even volunteer to do it, if that would be helpful). The question would be what type of output is needed to make this easy to use (e.g. list of bugs, or ?) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application version numbers, SC version numbers and FIXED-IN
El Dijous, 27 de desembre de 2012, a les 18:27:25, Michael Pyne va escriure: On Thursday, December 27, 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. We can instead query the git repository directly for commit messages containing '^BUG: ' or '^FIXED-IN:' (and its alternates) within the commits between the old and new version. Which means someone needs to do a lot of work (lot of work, getting all the new and old versions for more than 100 repos and then running the script and then putting it somewhere in the web) Coding the script is the easy part, finding someone to run and maintain it is the hard part. Of course the great part would be having this run automagically. There's an existing script which figures out how to generate a changelog from the old XML based on a version number which would probably be easy to adapt (and I'd even volunteer to do it, if that would be helpful). The question would be what type of output is needed to make this easy to use (e.g. list of bugs, or ?) No clue, to be honest i think we have mch more important things to do, just put the SC version in the FIXED-IN field and save everyone's time, or am i seeing things wrong? Cheers, Albert Regards, - Michael Pyne ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Application version numbers, SC version numbers and FIXED-IN
On Thursday 27 December 2012 23:42:15 Albert Astals Cid wrote: El Dijous, 27 de desembre de 2012, a les 16:16:55, Allen Winter va escriure: On Thursday 27 December 2012 11:57:28 AM Aurélien Gâteau wrote: Hi, Gwenview version number is 2.x.y, where x.y follows KDE SC 4.x.y (meaning KDE SC 4.9.5 ships Gwenview 2.9.5). Until now we have been using Gwenview version numbers for Bugzilla FIXED-IN fields but it has been brought to my attention that doing so means Gwenview fixes do not get listed in the Bugzilla link. We could get rid of the notion of Gwenview version numbers and just use KDE SC version numbers, but I don't think this would work for example for KMail. For the record, most kdepim apps use the same version number as KDE SC. Including KMail2, KOrganizer, Akregator, KAddressbook... Is there an established policy for this? Not to my knowledge. Should we use KDE SC version numbers in the FIXED-IN field? Good question. The definition of Version Fixed In is A custom Free Text field in this installation of KDE Bugtracking System. Therefore, you could put the KDE SC version *and* the Gwenview version both. The problem with this is that then the bugzilla query we use to create the changelog won't work, e.g https://bugs.kde.org/buglist.cgi?query_format�vancedshort_desc_type=allwo rdssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=RES OLVEDbug_status=VERIFIEDbug_status=CLOSEDemailtype1=substringemail1=ema ilassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bu gidtype=includebug_id=votes=chfieldfrom 11-06-01chfieldto=Nowchfield cf_versionfixedinchfieldvalue=4.9.4cmdtype=doitorder=Bug+Numberfield0-0- 0=nooptype0-0-0=noopvalue0-0-0 You could argue that this is the fault of the query not being good enough, and i'd agree, but not sure how we can improve this situation. I don't think that this query could be further improved - maybe with target milestones, but they need to be set manually and would still require an app to use the SC version numbers. Back at Akademy Jeroen showed some MediaWiki magic to automize the changelog. Maybe we could transit to something like that, then the maintainers just need to provide a kind of pattern for their version numbers? Cheers Martin signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
