The new scripts also automatically generate the CHANGES and README files.
(Of course it's also possible to run those Yetus scripts as part of the
make-rc release process)
On Sat, Jan 16, 2021 at 6:38 AM Istvan Toth wrote:
> Hi!
>
> I can see that Xinyi has filed PHOENX-6319 and PHOENIX-6320
Hi!
I can see that Xinyi has filed PHOENX-6319 and PHOENIX-6320 for the "old"
make_rc script.
While of course every release manager is free to choose to the tools they
use, I ask you to consider using
the HBase-derived scripts at dev/create-release in the master branch. They
are not copied to
Thank you for the update and great work, Istvan. I feel the same way, this
is the best approach so far for 4.16 and 5.1.
On Tue, Jan 12, 2021 at 7:01 PM Josh Elser wrote:
> IMO, a slow build is better than forcing users to run their own dev
> build of a release.
>
> Very proud of all of the
IMO, a slow build is better than forcing users to run their own dev
build of a release.
Very proud of all of the work y'all have been doing on 4.16. Keep
pushing on the release :)
On 1/12/21 12:35 PM, Istvan Toth wrote:
I've been working this, and came up with the following:
* We no longer
I've been working this, and came up with the following:
* We no longer generate phoenix-client.jar and phoenix-server.jar, we call
them phoenix-client-hbase-X.Y.jar and phoenix-server-hbase-X.Y.jar instead.
* These file names are used in the binary assemblies, as well as as maven
coordinates for
As I started to work on this I realized that while providing binary
tarballs for each HBase profile is fine,
this does not solve the maven artifact issue.
Are we OK with publishing a single phoenix-client maven artifact (for the
oldest HBase),
or do we want to publish a separate one for each
On the release binaries:
The current solution (which the default profile change has broken) was
based on Lars's idea at
https://issues.apache.org/jira/browse/PHOENIX-5902?focusedCommentId=17125122=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17125122
However, I agree
If we can modify the dev/create-release scripts and make them work for the
4.16 release with this hbase.profile option, it would make our life much
easier to release multiple HBase profiles from the single branch in the
future too(the master branch will have a release shortly right?). Geoffrey
and
Thanks for bringing up the default branch issue, Istvan, I've been meaning
to start a conversation about it on this list.
As part of PHOENIX-5435, I changed the default 4.x HBase release to 1.5 and
the default 5.x HBase to 2.3 because the WAL annotation feature introduced
by 5435 only works with
Two more issues came to my mind:
In PHOENIX-5435 the default profile was changed to HBase 1.5.0
This causes two conflicts:
- Our documentation says that the default profile is the lowest supported,
which is no longer true
- Unless we change our binary release process, the published maven
Hi!
A question of process: Should we backport fixes to the 4.16 branch at our
discretion, or is backporting those handled by the release manager (Xinyi) ?
On Thu, Jan 7, 2021 at 5:42 AM Istvan Toth wrote:
> Hi!
>
> Thanks for everyone's effort on fixing the flakey tests.
> However, our ASF
Hi!
Thanks for everyone's effort on fixing the flakey tests.
However, our ASF Jenkins runs are still very unstable, and I am afraid that
the single clean 4.x run was down more to luck than to fixing the
underlying problem.
While I do not consider this a blocker, fixing this would make the pre-
Hi,
We finally have a stable 4.x branch build after many flapper test fixing
contributions from the community. I'm going to fork a new branch(4.16) from
the current 4.x branch for the 4.16 release. As a cutoff, I will not
include any new features other than PHOENIX-6211 and bug fix. Please let me
An update on test stability:
As per recent 4.x build results, we are left with very few flappers and
specifically
with HBase profile 1.6, I can see recent 7 build (multibranch + PR
precommit results)
results without any test failure.
On Tue, Dec 15, 2020 at 5:52 AM Xinyi Yan wrote:
> Yes, we
Yes, we are currently working on fixing the 4.x branch test flappers while
waiting for the PHOENIX-5435. After that, I will try to have an RC ASAP.
On Sun, Dec 13, 2020 at 3:29 PM Ankit Singhal
wrote:
> I see that both the blockers listed here PHOENIX-5712 and PHOENIX-6241
> have been
I see that both the blockers listed here PHOENIX-5712 and PHOENIX-6241
have been resolved(Thanks to Xinyi), and also as per the JIRA query there
is no Jira marked as a blocker for 4.16 except the one related to
documentation
for "splittable catalog table".
Xinyi, so are we good to start the
Thanks for replying and providing suggestions. I looked at the wrong result
Jira list that Daniel provided and did some local testing, and here is the
result:
[resolved] PHOENIX-4116, PHOENIX-4419, and PHOENIX-4642: cannot reproduce
it.
[More information is required] PHOENIX-4504 cannot reproduce
Thanks Daniel and appreciate the effort you put in getting the list ready
for bugs producing wrong results
but none of them seems to be a blocker to me for 4.16 as they are not the
regression and doesn't break the general functionality
except for specific features, RVC/desc as Chenglei also
In my opinion, we should keep releases light and frequent, and for some
unusual query bugs like RVC and DESC
we could delay fix to next release . I think we should release 4.16.0 and 5.1.0
as quickly as possible. In China, many users
in HBase User Group thought that Phoenix was dead
I agree. These are all major bugs and we should aim at solving them after
checking that they are still issues. I am +1 on 5833 and I think 5484 would
be a great addition to 4.16 as well. We should aim at resolving high
priority bugs like this in every release.
Sometimes we let these bugs slip
I've got PHOENIX-5435 in review right now, and would like to get it in 4.16
/ 5.1.
It's allowing the annotation of Phoenix metadata into HBase WALs as a
pre-req for the Phoenix Change Detection Capture framework (PHOENIX-5442).
Since it has both client/server logic, and adds a field to
Hi, I wanted to bring up wrong results in Phoenix and some JIRAs around
them that I think we should fix as the wrong result lessens the end user's
trust in Phoenix. Releasing a new version without addressing these in a
minor release hurts our visibility in that these critical issues are not
Hi all,
It's time to discuss the Phoenix 4.16 release. After many people's
contributions on the bug fixes, new features, and other works in the past
few months, we are kind of close to the point to have a RC (still need to
fix test flappers). Please let me know if you think any JIRA must be part
23 matches
Mail list logo
