Not sure. Mean, those "-rcX" are be voted on. We do not push "-rcX" jars
to Maven Central, but would push Docker images.
It's also that it's not us who configure the users' renovate/dependabot ;)
Which is actually my fear, that users get those rc-images although those
are not officially released.
On 13.06.25 19:06, Alex Dutra wrote:
Hi Robert, hi all,
I do agree with you that we need to distinguish between nightlies and
production-ready artifacts, mainly because these repositories will be
fed by fairly diverse pipelines: nightly images will be provided by an
automated pipeline with no guarantee whatsoever about the contents it
produces; while production images will be provided by a semi-automated
pipeline triggered by the release manager, and thus under human
control.
But I was thinking that maaaaybe there is a way to spare ourselves the
creation of the "staging" repository: in an Apache project, all
pre-release artifacts are release candidates and have versions like
X.Y.Z-rc1, rc2, etc. I think it would be reasonable to just push the
rc1, rc2 images to the "production" repository, provided that we can
configure Renovate and other bots to skip release candidates. In this
scenario, when the release passes, the release manager would simply
push another image to the same repository without the "rcX" suffix.
Does that sound like a reasonable compromise?
Thanks,
Alex
On Fri, Jun 13, 2025 at 1:53 PM Robert Stupp <sn...@snazy.de> wrote:
I was thinking of how the Docker images are being staged and eventually
released. I know there was a dev-ML thread about this, but I think this
topic is important for the 1.0 release, so raising it here.
The release-guide doesn't mention images at all, so the process isn't clear.
TL;DR of my reasoning is that we likely need 3 (!) repositories for both
the server and admin-tool:
* one for nightlies
* one for staging (before release-vote passes)
* one for released versions
Due to the nature and restrictions of image repositories (no notion of
"snapshots") we cannot push "pending releases" to the 3rd one, because
tools like renovate of dependabot would blindly use those (same problem
as nightlies vs releases).
Thoughts?
On 16.05.25 04:31, Jean-Baptiste Onofré wrote:
Hi Yufei
Thanks for your message !
It looks good to me.
As prerequisite (obviously), we should also complete
0.10.0-beta-incubating release to be sure we are good there before
1.0.0.
Just a comment: I think we should limit the number of community
meetings. This topic should be typically discussed on the mailing list
(as you are doing :)).
The reasons why I'm not big fan of too much meeetings are:
1. No everyone in the community can join (due to timezone, not willing
to speak/appear on call, ...)
2. It puts "pressure" on the community to attend ("if I'm not in the
meeting, I'm not in the community" issue)
3. Due to 1 & 2, no decision should be taken in meetings, and even if
meetings are recorded, it's not archive as mailing list
So, I encourage meetings as community meet&greed, or to discuss about
specific topics, not decision making topic.
Thanks,
Regards
JB
On Thu, May 15, 2025 at 11:38 PM Yufei Gu <flyrain...@gmail.com> wrote:
Hi folks,
Many users have been asking about the Polaris release, and I believe it's
critical to have a formal, production-ready 1.0 release ASAP. Thanks to the
community’s hard work, we’re very close with a few remaining blockers we
need to resolve.
To keep things moving, I scheduled a community meeting for the 1.0 release
next Monday at 9 AM PST. At the same time, sharing all issues marked with
1.0 blocker. We could resolve them here if possible. Feel free to chime in,
remove the blocker tag if you think it's not a blocker, or pick any up.
Thanks a lot in advance!
Here is the list:
- Add CI for Python code (
<https://github.com/apache/polaris/issues/1058>#1058),
- Polaris persistence concurrency issues (#777)
<https://github.com/apache/polaris/issues/777>
- Task handling is incomplete (#774)
<https://github.com/apache/polaris/issues/774>
- Generated files in regtests/client/python/polaris (#755)
<https://github.com/apache/polaris/issues/755>
- Resources not properly closed, resource & memory leaks (#563)
<https://github.com/apache/polaris/issues/563>
- Make Polaris safe against certain unparseable locations (#552)
<https://github.com/apache/polaris/issues/552>
- [BUG] Assumption that cache eviction does not happen (#544)
<https://github.com/apache/polaris/issues/544>
To make it more interactive, you can also comment on the google
spreadsheet here:
https://docs.google.com/spreadsheets/d/1GyLvp2cdYwioOsBwszNWiphZt_IIdo4LIfsZBFV88mc/edit?usp=sharing
Yufei
--
Robert Stupp
@snazy
