[Qgis-developer] backported fixes

[Matthias Kuhn]

On 06/04/2015 11:26 AM, Sandro Santilli wrote:
> 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 ...
I did an example:

http://hub.qgis.org/issues/12867

> 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;
-1
I don't open tickets for bugs which I fixed and found no ticket. I am
too lazy.
I'd rather have a solution that merges the commit log and the ticket
information into a single, good-looking changelog.

Matthias