Would love another discuss thread on that tangent, because I completely
agree and think it warrants some discussion.
In terms of the original takeaways here, I'm now auditing the jiras which
have fixVersion = 2.6.0 but which existed in branch-2.5 prior to the
release of 2.5.0. There are only 31 of
I’m late to the discussion, but you’ve concluded on what I believe is the
correct approach. Another way to consider why this approach is correct is
to think in terms of “git time” instead of chronological time. Consider the
last common ancestor commit in the git histories. branch-2.6 was created
fr
Thanks for the history dive :)
> but not all the commits in 2.5.1 will go into 2.6.0, even if 2.6.0 is
released after 2.5.1.
I actually had the same thought after sending my last response. There might
also be bug fixes that only apply to 2.5.x. This, along with historical
convention, seems like a
I checked the history a bit...
For 2.0.0, the previous version is 1.0.0...
https://github.com/apache/hbase/blob/branch-2.0/CHANGES.md
For 2.1.0 and 2.2.0, we do not include the previous version in the
CHANGES.md, but you can pick some issues, usually it will have a 2.0.x
or 2.1.x fix versions.
Thanks again for the back and forth here, both. It seems like there is no
single right solution, which in my opinion is not great. It’s
understandable though because historically it’s been hard to enforce a
standard.
The release process is involved but largely automated. One piece not
automated ye
If you use 2.5.7 as the previous version of the 2.6.0 release then only the
changes committed to branch-2.6 not also committed to branch-2.5 at time of
release need a fixVersion of 2.6.0. This can be analyzed with a compare tool
looking at the respective branches while ignoring any commits on br
It is based on how you construct the CHANGES.md.
If in the CHANGES.md, your previous version is 2.5.0, then you should
include all the issues committed to branch-2.6 which are not included
in 2.5.0. If your previous version is 2.5.7, then you should include
the issues from 2.5.7.
For me, I think
Ok I can do that but I don’t think that’s quite what Andrew described,
unless I misunderstood.
On Mon, Jan 22, 2024 at 6:28 PM 张铎(Duo Zhang) wrote:
> You should only remove 2.6.0 when fix versions = 2.5.0 :)
>
> Bryan Beaudreault 于2024年1月23日 周二06:32写道：
>
> > Andrew, I'd like to clarify something
You should only remove 2.6.0 when fix versions = 2.5.0 :)
Bryan Beaudreault 于2024年1月23日 周二06:32写道：
> Andrew, I'd like to clarify something before I act --
>
> I have a script which has identified 300+ jiras where fixVersion is 2.6.0,
> but the commit exists in branch-2.5. Most of those have a fix
Andrew, I'd like to clarify something before I act --
I have a script which has identified 300+ jiras where fixVersion is 2.6.0,
but the commit exists in branch-2.5. Most of those have a fixVersion <
2.5.8. Here's a couple examples:
- https://issues.apache.org/jira/browse/HBASE-28245 -- has 2.6.0
Thank you both for the input. That's a good idea Andrew, I'll take a stab
at it.
I have a script (based on Nick's git-jira-release-audit [1]) which I'm
using to audit versions. I'll see if I can add this to that so we can
automate that cleanup for future .0 releases.
[1]
https://github.com/apache
For 2.5.0 I based the change log on the change log of what was then the
last/most recent 2.4 release. Anything committed into 2.4 with a fix version of
2.5, I dropped the 2.5 fix version. The 2.5 fix version was kept for anything
novel in 2.5. The result was an orderly cumulative change log. I a
Usually we will only set fix version if there is a commit.
The only exception is for some umbrella issues where we want to put a
fat release note there, such as HBASE-26067.
This will introduce some difficulties to the RMs as it will cause
mismatches on the commit history and CHANGES.md. But anyw
13 matches
Mail list logo
