We might be able to help with that.
Founder - https://commandprompt.com/ - 24x7x365 Postgres since 1997Founder and
Co-Chair - https://postgresconf.org/ Founder - https://postgresql.us - United
States PostgreSQLPublic speaker, published author, postgresql expert, and
people believer.Host - More
Hi,
One more request from the community member, FYI: Any chance to provide
one official docker image for the new release?
Best,
Dianjin Wang
On Fri, Mar 7, 2025 at 11:33 AM Dianjin Wang wrote:
>
> As the first phase of the cherry-pick work nears completion, I believe
> it’s time to start prepar
Hi hackers,
We’re working on contributing the PAX feature and aim to complete it by
March. Since this feature involves catalog changes, we’d like to have it
included in the 2.0 release.
I agree that it’s a good time to start preparing for the 2.0 release.
On Fri, Mar 7, 2025 at 11:36 AM Dianjin W
As the first phase of the cherry-pick work nears completion, I believe
it’s time to start preparing for the Cloudberry 2.0 release as Reshke
asked earlier this week.
I would like to provide some inputs for consideration from my perspective:
* High Priority: Cleanup PRs (#731, #812, #920) should be
It's good that we are starting to work on the pg_upgrade now.
On Sat, Feb 22, 2025 at 3:23 PM Kirill Reshke wrote:
> On Thu, 30 Jan 2025 at 00:14, Kirill Reshke
> wrote:
> >
> > I tried gp_upgrade once again today. Our gp 6 fork is here[1].
> > Currently, there is some vital work from GP7 missi
On Thu, 30 Jan 2025 at 00:14, Kirill Reshke wrote:
>
> I tried gp_upgrade once again today. Our gp 6 fork is here[1].
> Currently, there is some vital work from GP7 missing in CBDB, so I did
> a cherry-pick PR [2]. Most probably, gpupgrade will need some more
> attention after [2] merged, this is
I tried gp_upgrade once again today. Our gp 6 fork is here[1].
Currently, there is some vital work from GP7 missing in CBDB, so I did
a cherry-pick PR [2]. Most probably, gpupgrade will need some more
attention after [2] merged, this is what I'm currently working on.
[1] https://github.com/open-g
Recommend a beta 2.0.0-rcX tagged release. Permits general testing
including other projects such as cloudberry-gpupgrade.
For us (Mountain), dump-restore is not appealing.
On Tue, Jan 28, 2025 at 7:22 AM Kirill Reshke
wrote:
> We should support gp_upgrade (a wrapper around pg_upgrade) someday,
We should support gp_upgrade (a wrapper around pg_upgrade) someday,
but for now - gpdump + gprestore I guess.
On Fri, 24 Jan 2025 at 20:30, Greg Spiegelberg wrote:
>
> A lot of work has gone into the next release and I applaud all of it.
>
> what is the anticipated upgrade path?
>
> -Greg
>
Best
A lot of work has gone into the next release and I applaud all of it.
Because this will be a major release, what is the anticipated upgrade path?
-Greg
On Thu, Jan 23, 2025 at 1:34 PM Joshua D. Drake
wrote:
> Howdy,
>
> I would agree that completing the Cherry Pick work makes sense.
>
> JD
>
>
Howdy,
I would agree that completing the Cherry Pick work makes sense.
JD
- Founder - https://commandprompt.com/ - 24x7x365 Postgres since 1997
- Founder and Co-Chair - https://postgresconf.org/
- Founder - https://postgresql.us - United States PostgreSQL
- Public speaker, published
Hi guys,
I would like to bump this discussion again.
In Slack and other channels, a few community members have been asking about
our first Apache release. Now our contributors are actively working on
cherry-picking commits from the GP archived repo to Cloudberry[1].
IMO, it would be better to re
Hi team,
It's great to see such active discussions! Just a friendly reminder that
our project name has been changed to Apache Cloudberry. So when referring
to the project, please feel free to use `Apache Cloudberry` or `Cloudberry`
going forward. Let's avoid using "Cloudberry Database" in the futu
Hi All,
I appreciate the ongoing discussion regarding the versioning strategy for
Cloudberry Database.
I wanted to share my perspective on why I strongly believe we should adopt
semantic versioning (major.minor.patch) instead of the “year.release.patch”
format seen in Clickhouse.
1. Alignment
I like the Clickhouse year version number thought but feel it doesn't
communicate enough and could potentially mean a 2024 major release is where
Cloudberry is at in 2025 which is not a message worth communicating.
Along the year number line of thought, consider PostgreSQL does major
releases annu
Lots of great thoughts in this thread. Just want to share the sentiment as
someone who did professional services for Greenplum for almost a decade
that something like pg_upgrade would be really *really *great to have to
perform whatever conversions need to happen for major upgrades with the
user da
On Mon, Dec 9, 2024 at 3:27 AM Ed Espino wrote:
>
> Hi Andrey,
>
> Thanks for bringing up the ClickHouse versioning model - it's a fascinating
> alternative to consider. I particularly like how the year-based scheme
> instantly communicates version currency to users and the tiered
> functionality
Hi Andrey,
Thanks for bringing up the ClickHouse versioning model - it's a fascinating
alternative to consider. I particularly like how the year-based scheme
instantly communicates version currency to users and the tiered
functionality approach.
After considering both approaches, I still lean tow
Hi Ed,
Agree that we have the first version 2.0 first, which can help us go
through the entire process
and run the release pipeline.
Generally speaking, the time for the first release will be longer than
later. Thank you for volunteering as the release manager.
Your many experiences will definite
Hi Andrey,
Good to see you!!!
Yes, we need to add some checks in codes to let the program automatically
discover incompatible issues.
As for the issue of functional classification, it can be added with
corresponding tags during code review, and the document can be
associated with this information
> On 9 Dec 2024, at 11:26, Max Yang wrote:
>
> Welcome to discuss
Hi!
Let’s consider also Clickhouse versioning.
Clickhouse version is “year.release.patch”. Also they add tags “stable” or
“lts” to some releases.
The basic idea is that you have continuous development process not tied to
sp
Hi Max,
Thank you for raising these important points about release strategy. As
someone who has volunteered to be Release Manager for our initial Apache
releases, I'd like to share some thoughts:
1. I strongly agree with your semantic versioning proposal. You've
outlined it well - major.min
22 matches
Mail list logo
