Application version numbers, SC version numbers and FIXED-IN

[Martin Gräßlin]

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=advanced&short_desc_type=allwo
> rdssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=
> allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=RES
> OLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&ema
> ilassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bu
> gidtype=include&bug_id=&votes=&chfieldfrom=2011-06-01&chfieldto=Now&chfield=
> cf_versionfixedin&chfieldvalue=4.9.4&cmdtype=doit&order=Bug+Number&field0-0-
> 0=noop&type0-0-0=noop&value0-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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20121228/97873e86/attachment.sig>