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
unity and demonstrates our commitment to best
> > > > practices.
> > > >
> > > > 6. Future-Proofing Cloudberry: As we grow and evolve, semantic
> versioning
> > > > offers a robust framework that can scale with us. It allows us to
> introduce
&
adopting semantic versioning, we can solidify our
> > > project’s foundation and enhance the overall experience for our users.
> > > I look forward to hearing your thoughts.
> > >
> > > About frequency of our Cloudberry Database releases.
> > > I agree w
ur thoughts.
>>
>> About frequency of our Cloudberry Database releases.
>> I agree with the sentiment that we should not release very often.
>> Stability is crucial for a database, and prioritizing a stable release
>> schedule will ultimately benefit our users.
>>
ment that we should not release very often.
> Stability is crucial for a database, and prioritizing a stable release
> schedule will ultimately benefit our users.
>
>
> Best regards,
> Zhang Mingli
>
> On 2024/12/09 06:26:13 Max Yang wrote:
> > Hi All,
> >
>
should not release very often.
Stability is crucial for a database, and prioritizing a stable release schedule
will ultimately benefit our users.
Best regards,
Zhang Mingli
On 2024/12/09 06:26:13 Max Yang wrote:
> Hi All,
>
> We need to consider when to release Cloudberry 2.0, and
> > > > >major version bump when it happens, but shouldn't be a blocker
> > for 2.0
> > > > > if
> > > > >we have other breaking changes to address.
> > > > >
> > > > > As a next step, I propose working on our fi
; if
> > > >we have other breaking changes to address.
> > > >
> > > > As a next step, I propose working on our first Apache releases to
> > > establish
> > > > our processes. This experience will help us better plan and execute
> both
&
familiar with the process
> > > and requirements. I'm ready to shepherd both the release process and this
> > > versioning discussion, with the goal of working toward a 2.0 release
> > (given
> > > our likely incompatibilities) and potentially a 1.6.X release. While
> > our likely incompatibilities) and potentially a 1.6.X release. While we
> > still have some process work to complete before we're ready for these
> > initial releases, I'm committed to helping drive this forward.
> >
> > Would others like to share their thoug
releases, I'm committed to helping drive this forward.
>
> Would others like to share their thoughts on this approach?
>
> Looking forward to the discussion,
> -=e
>
> On Sun, Dec 8, 2024 at 10:26 PM Max Yang wrote:
>
> > Hi All,
> >
> > We nee
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
d others like to share their thoughts on this approach?
Looking forward to the discussion,
-=e
On Sun, Dec 8, 2024 at 10:26 PM Max Yang wrote:
> Hi All,
>
> We need to consider when to release Cloudberry 2.0, and how often to
> release it, which involves the following consideratio
Hi All,
We need to consider when to release Cloudberry 2.0, and how often to
release it, which involves the following considerations:
The version number consists of three parts: < major >. < minor >. < patch
>, namely x.y.z.
In the Greenplum release, the bump of major to major
23 matches
Mail list logo
