Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Eric Maynard
Sorry, I missed this point about 1.1.0… so Helm Chart 1.1.0 will point at what commit from Polaris? Not the 1.1.0 release, right? Is the alternative that we just cut a 1.0.1 for Polaris and the Helm chart? On Mon, Jul 21, 2025 at 10:06 PM Jean-Baptiste Onofré wrote: > Hi, > > I would propose Po

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Jean-Baptiste Onofré
Hi, I would propose Polaris Helm Chart 1.1.0. It seems we have a consensus here, so let me move forward on the release prep :) Thanks ! Regards JB On Tue, Jul 22, 2025 at 1:48 AM yun zou wrote: > > Hi JB, > > An official release for just the Helm Chart sounds like a reasonable plan > to unblo

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread yun zou
Hi JB, An official release for just the Helm Chart sounds like a reasonable plan to unblock the user as soon as possible. I have a quick question, would the Helm Chart version be "1.1.0" or "1.0.1"? Since it releases from main, I felt it should be 1.1.0, instead of 1.0.1. I would really appreciat

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

2025-07-21 Thread Dmitri Bourlatchkov
Hi Robert, > There is already a way to rotate credentials [...] I do not think so. Currently, Polaris allows only the Principal itself to rotate the credential it owns. Admin / root cannot rotate credentials for another Principal. Cheers, Dmitri. On Mon, Jul 21, 2025 at 4:32 AM Robert Stupp

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Robert Stupp
IIUC the idea is to release only Helm, nothing else. On Mon, Jul 21, 2025 at 4:43 PM Dmitri Bourlatchkov wrote: > > A helm + source release from `main` SGTM. > > Just to be clear: we'll be releasing the full source (including java) > bundle from the latest `main`, but will only publish binaries f

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Dmitri Bourlatchkov
A helm + source release from `main` SGTM. Just to be clear: we'll be releasing the full source (including java) bundle from the latest `main`, but will only publish binaries for helm charts 1.0.1, right? Cheers, Dmitri. On Mon, Jul 21, 2025 at 7:17 AM Jean-Baptiste Onofré wrote: > Thanks for y

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Robert Stupp
I didn't object to doing that, just raised things that should IMHO be considered. WRT tag - I'd prefix it with `helm/...` or so to not confuse any release-automation code. On Mon, Jul 21, 2025 at 1:17 PM Jean-Baptiste Onofré wrote: > > Thanks for your feedback Robert. > > What about doing Helm C

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Jean-Baptiste Onofré
Thanks for your feedback Robert. What about doing Helm Chart release now from the main repo (just with a dedicated tag and source distro) and then move forward on separate repo after this release ? We can “unblock” the users with an official release and then prepare the next release. Regards JB

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Robert Stupp
Hi all, regarding the consensus, let's quickly recap the options here: 1. Keep Helm chart releases with the "main" Polaris release 2. Separate Helm charts releases For 1) there's nothing to be done. Helm Charts releases would be drafted ("RC") and eventually released ("GA") as an orthogonal effo

Re: [Discussion] Decoupling Helm chart releases (+ nightly build proposal)

2025-07-21 Thread Jean-Baptiste Onofré
Hi Yun I would propose to focus on the following: 1. We have a "isolated" release cycle for Helm Chart 2. We do a Helm Chart release as soon as we need to fix/unblock users Snapshot is not a release (official one), so, not sure it actually helps (or just for testing purpose). In order to move fo

Re: Proposal: Optional clientId / clientSecret in createPrincipal API for Migration Support

2025-07-21 Thread Robert Stupp
There is already a way to rotate credentials, so I am not sure what the benefit of a "reset password" workflow would be. I do see the disadvantage that 0.9 doesn't have "external IdP" support, but 1.0 has it. I also see that you have trouble with keeping both versions alive. However, we have to be