On Sep 3, 2014, at 4:57 PM, Chris Douglas <cdoug...@apache.org> wrote:
> On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer <a...@altiscale.com> wrote:
>> We’ll also need to get much more strict about Fix Version really only
>> listing the earliest version. Many of list (next release) + (trunk), myself
>> included, which after looking through some of the commit docs, is not
>> correct.
>
> Is this really preferable to listing the set of branches to which it
> was committed? We don't necessarily maintain a total order for version
> numbers, so it's usually more valuable to know when this was fixed in
> branch-N. -C
I think HowToCommit is pretty much covering this case and the normal workflow
for 99% of the patches, though. It depends upon ones interpretation of the
word 'mainline'. The simple case:
* Patch gets committed to trunk and branch-2
* Fix version gets set to 2.6.0, with an implicit commit to trunk at the same
time
* Changes.txt reflect that change was made in 2.6.0 for all immediate,
subsequent releases
If a change goes into another branch that the main release doesn't come from,
(e.g., 0.23.x, fs-encryption, whatever), then, as HowToCommit points out, that
*should* be listed in fixVersions as well. There is *zero* impact on the
mainline release since any JIRA documentation will be tied to the fixVersion.
(This does mean, however, merges from non-mainline branches will need to have
the fixVersion set to the version it was merged into….)
What happens if there are effectively *two* mainline releases though? We had
this situation already with branch-1 and branch-2. For a patch that goes to
let's say 1.2.0 and 2.3, it's not spelled out, but implied that they should
both be listed as both are mainline. 2.3 isn't going to regenerate the change
log from 1.3 because it was cut well before that release appeared. They've
diverged and they are effectively separate tracks at that point.
Things get slightly tricky if a release is skipped. Let's say we realize that
doing 2.7 is kinda dumb and jump straight to 3.0. Alas! We have patches for
2.7! Then when release notes/changes.txt is generated, you simply point it to
2.6 instead of 2.7 and those changes will show up as appropriate.
Speaking of, one thing we rarely talk about is the release notes generator. It
has effectively the same issues as if we were to pull the changes.txt from
JIRA. Running it against 3.x, today, generates a pretty big mess as a result
of all of us breaking the fixVersion rule.
FWIW, I took that code and hacked it up to generate changes.txt. Someone more
fluent in python could likely do a better job, but at least as a prototype it's
showing promise… But it does show even more problems when generating a 3.0.0
changes file. Even with a lot of cleanup, it thinks there are over 400 patches
just for 3.0…. clearly wrong given I think the total number of changes in trunk
only is probably below 50.
