[Qgis-developer] backported fixes

[Sandro Santilli]

On Thu, Jun 04, 2015 at 11:06:31AM +0200, Matthias Kuhn wrote:

> However, if you leave the "Fixes #XXXX" message in place it will
> generate a new hash when backported (cherry-picked), which will be
> linked in the ticket as well and return release-2_8 when evaluated by
> the tracker.
>
> The downside of this approach is that we do know that it's fixed in
> release-2_8 but not in which point release. So if I fix something today
> it says "fixed in 2.8" but to be precise it should say "fixed in 2.8.3".

True, we don't know about the future (who does?).
What we can know, though, is which release came out from that branch last:

 $ git describe
 final-2_8_2-9-gea447e7

So, 2.8.2 was the latest, and "we" (a plugin?) may assume 2.8.3 will be
the next.

I don't like the version in the commit log because if you further
cherry-pick that commit in another branch it brings with it the target
version info which doesn't really belong to the change. In postgis I often
cherry-pick commits from svn-trunk to svn-21 to svn-20 ...

> We could also go the other way and take the release-2_8 branch history
> as canonical source for fixes/Changelog.

That's surely the most detailed and correct info.

> For me the two things are different:
> 
>  * The changelog (with fixes that *may* have a ticket attached)
>  * The ticket that should contain information about on which branches it
> has been resolved

Agreed. So back to Paolo's request:

On Wed, Jun 03, 2015 at 06:29:36PM +0200, Paolo Cavallini wrote:
> My aim was to give "normal" users an easy way of
> discovering whether they can expect a fix in the next LTR release, or if
> they have to head for next release.

I think "normal user" refer to "a fix" by looking at a ticket,
so this whole discussion should be about making retriving the info
from the ticket easier.

For sure the first step is _ensuring_ that any fix has a ticket.
Then, the ticket should allow containing information about versions
in which the fix was committed. Either using the existing "Target Version"
field (which would need to be turned into an array or represent the "Minimum
Target Version"), or adding a new field.

--strk;