Application version numbers, SC version numbers and FIXED-IN

[Albert Astals Cid]

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