Re: [DISCUSS] 5.2.0 priority : PHOENIX-7106 Data Integrity Issues

I agree, this is a few lines (if it works) which takes no time to backport, so we need not hold up cutting the release branch for this. The HBase 2.5 and 2.5.0 profiles work fine with Hadoop 3.2.4, as expected, so updating those is kind of a non-brainer. I see many errors on the 2.4.0 and 2.4

Re: [DISCUSS] 5.2.0 priority : PHOENIX-7106 Data Integrity Issues

Sure let's go for it. I understand downstreamers are not happy with CVEs coming from our artifacts that were released in 2022. On Thu, Feb 15, 2024 at 6:05 PM rajeshb...@apache.org < chrajeshbab...@gmail.com> wrote: > Would be better to bump up Hadoop to 3.3.x I feel which has minimal >

[jira] [Assigned] (PHOENIX-7217) MaxLookback and TTL improvements and fixes

[ https://issues.apache.org/jira/browse/PHOENIX-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viraj Jasani reassigned PHOENIX-7217: - Assignee: Viraj Jasani > MaxLookback and TTL improvements and fixes >

[jira] [Created] (PHOENIX-7217) MaxLookback and TTL improvements and fixes

Viraj Jasani created PHOENIX-7217: - Summary: MaxLookback and TTL improvements and fixes Key: PHOENIX-7217 URL: https://issues.apache.org/jira/browse/PHOENIX-7217 Project: Phoenix Issue Type:

Re: [DISCUSS] 5.2.0 priority : PHOENIX-7106 Data Integrity Issues

Would be better to bump up Hadoop to 3.3.x I feel which has minimal vulnerabilities compared to Hadoop 3.2.4. Thanks, Rajeshbabu. On Fri, Feb 16, 2024, 7:25 AM Viraj Jasani wrote: > Sure it sounds good to create PR for version upgrades while we are getting > close to releasing 5.2.0 and 5.1.4.

Re: [DISCUSS] 5.2.0 priority : PHOENIX-7106 Data Integrity Issues

Sure it sounds good to create PR for version upgrades while we are getting close to releasing 5.2.0 and 5.1.4. However, if the build has unexpected test failures, we can cut 5.2 first, and focus on stabilizing the upgrade changes on master branch PR rather than 5.2 branch, allowing faster release.

[jira] [Updated] (PHOENIX-7216) Bump Hadoop version to 3.2.4 for HBase 2.4.x and 2.5.x profiles

[ https://issues.apache.org/jira/browse/PHOENIX-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7216: - Summary: Bump Hadoop version to 3.2.4 for HBase 2.4.x and 2.5.x profiles (was: Bump Hadoop

[jira] [Updated] (PHOENIX-7193) Fix cluster override for mapreduce jobs for non-ZK registries

[ https://issues.apache.org/jira/browse/PHOENIX-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7193: - Fix Version/s: 5.2.0 > Fix cluster override for mapreduce jobs for non-ZK registries >

Re: [DISCUSS] 5.2.0 priority : PHOENIX-7106 Data Integrity Issues

This comment got me thinking. Most of the community (i.e. SFDC and CLDR) does not particularly care about Hadoop and HBase dependency versions, as these are meant to be overridden anyway, and we both build our own binaries.

[jira] [Created] (PHOENIX-7216) Bump Hadoop versions to 3.2.4 for HBase 2.4.x and 2.5.x profiles

Istvan Toth created PHOENIX-7216: Summary: Bump Hadoop versions to 3.2.4 for HBase 2.4.x and 2.5.x profiles Key: PHOENIX-7216 URL: https://issues.apache.org/jira/browse/PHOENIX-7216 Project: Phoenix

[jira] [Updated] (PHOENIX-7215) Support explicit types for all literals

[ https://issues.apache.org/jira/browse/PHOENIX-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-7215: - Description: Phoenix accepts the standard literal types for date/time types. _select TIMESTAMP

[jira] [Created] (PHOENIX-7215) Support explicit types for all literals

Istvan Toth created PHOENIX-7215: Summary: Support explicit types for all literals Key: PHOENIX-7215 URL: https://issues.apache.org/jira/browse/PHOENIX-7215 Project: Phoenix Issue Type: