Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tracecompass-dev] Trace Compass 0.1.0 release preparation

Hello all Trace Compass committers and contributors,


As you may know, the 0.1.0 release is scheduled for February 27th. This will be Trace Compass' first release ever(!), and the only one before the big 1.0.0 one next June. (The attentive reader may notice this is the same date as the Luna SR2 release, although we are not in the Luna release train.)

We plan on branching a stable-0.1 branch on February 4th, to give about 3 weeks of stabilization before the actual release. Excluding exceptional circumstances, only bugfixes will be allowed in the stable-* branch. This means that any feature that you want to be part of the 0.1 release should reviewed and merged to master before February 4th.


When pushing a fix to a stable branch, I *highly* recommend that you first get it reviewed and pushed to master, and then cherry-pick it to stable. We've experienced a few cases in the past where a fix was put in a stable branch, but not in master, so the bug came up again in the following release! Not an ideal situation.

*After* your patch was merged in master, you can push it again to Gerrit targeting the stable branch ("refs/for/stable-0.1" in the .gitconfig). This will allow Hudson to build and run the tests on the new branch, which may expose unexpected problems. I also suggest you amend the commit message to add a line saying "corresponds to master commit e2bcc8a5" or similar.

If you cherry-pick the actual commit from master (and not your local one), please make sure to delete the lines that were added by Gerrit, like:

> Reviewed-on: https://git.eclipse.org/r/123456
> Reviewed-by: Hudson CI
> Reviewed-by: This Person <this.persona@this.company>
> Tested-by: This Other Person <this.other.person@this.company>

These refer to the original commit in master, so they are not necessarily relevant to the equivalent commit in the stable branch (especially not the "Reviewed-on" one, as another one will get added by Gerrit anyway when the patch is submitted). You can keep the same Change-Id, since Change-Id's are per-branch for Gerrit.


Thanks, and happy hacking!

--
Alexandre Montplaisir
Trace Compass project co-lead


Back to the top