Thanks a lot for the details, Alex! I agree that the impact may be limited in practice. That said, if the consensus is that the impact is minor and well covered by the upgrade notes, I am fine with keeping it as an upgrade note rather than explicitly labeling it as breaking.
Yufei On Wed, Feb 18, 2026 at 11:42 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi > > I don't think we should flag this as a breaking change. Just to note > to the users is enough imho. > > Regards > JB > > On Wed, Feb 18, 2026 at 7:33 PM Alexandre Dutra <[email protected]> wrote: > > > > Hi, > > > > The only case where an old config could be rejected is if it is using > > a "relaxed" syntax, e.g. if someone was **explicitly** overriding > > revisionHistoryLimit to "" instead of 0, then this would fail with the > > new chart, because revisionHistoryLimit is now of type [integer, null] > > and not string: > > > > helm template polaris helm/polaris --set revisionHistoryLimit="" > > Error: values don't meet the specifications of the schema(s) in the > > following chart(s): > > polaris: > > - at '/revisionHistoryLimit': got string, want null or integer > > > > I don't expect this to happen a lot to be honest. > > > > Thanks, > > Alex > > > > On Wed, Feb 18, 2026 at 6:38 PM Yufei Gu <[email protected]> wrote: > > > > > > > Re: "breaking change" - we do not have a formal statement about helm > > > evolution in [1], so I'm fine with treating it in a lenient manner for > > > 1.4.0. > > > > > > Whether or not we have a formal evolution statement, I believe this > should > > > be considered a breaking change if users will experience failures when > > > upgrading. > > > > > > > I assume values that match the new schema will also be acceptable in > the > > > old helm version. > > > > > > Is that actually the case? If not, then the upgrade impact seems > clearer. > > > Maybe Alex and Yong can confirm. > > > > > > Yufei > > > > > > > > > On Wed, Feb 18, 2026 at 8:37 AM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > Hi All, > > > > > > > > Re: "breaking change" - we do not have a formal statement about helm > > > > evolution in [1], so I'm fine with treating it in a lenient manner > for > > > > 1.4.0. > > > > > > > > I assume values that match the new schema will also be acceptable in > the > > > > old helm version. > > > > > > > > In general, I tend to think that helm value refactoring are on the > same > > > > "page" as SPI changes - before they hit production, users will use > them > > > > locally or in CI (assuming normal software development practices), > and they > > > > will discover the need for adjustments before anything "breaks". > > > > > > > > Helm values is a tool for Polaris to request input from the users. > It is > > > > not a tool for users to make Polaris do something other than what > the helm > > > > charts intend. Therefore, I believe users ought to expect changes in > helm > > > > values validation in every release. > > > > > > > > That said, I'm also open to flagging this as a "breaking change" in > > > > CHANGELOG, if that's what the consensus might be. > > > > > > > > I still believe it is not worth bumping the major version number, if > we > > > > were to treat it as a breaking change from the SemVer [2] > perspective. > > > > > > > > [1] https://polaris.apache.org/in-dev/unreleased/evolution/ > > > > > > > > [2] https://semver.org/ > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Wed, Feb 18, 2026 at 5:43 AM Alexandre Dutra <[email protected]> > wrote: > > > > > > > > > Hi all, > > > > > > > > > > Thanks to everyone for the feedback. > > > > > > > > > > Regarding user awareness: we've added a note to the changelog under > > > > > "Upgrade Notes": > > > > > > > > > > > The Helm chart now includes a JSON schema file for easy > validation of > > > > > values files. Because types are now validated, existing values > files may > > > > > need to be updated to match the new schema. > > > > > > > > > > I'm open to reclassifying this as a "breaking change" if people > think > > > > > it's necessary. I think the "breaking" nature is debatable, but I'm > > > > > fine with making the change. > > > > > > > > > > FYI I may merge the PR in the interim though because I have more > PRs > > > > > waiting on that one, but I can change the wording in the changelog > in > > > > > a follow-up PR to reflect the community's opinion. > > > > > > > > > > Thanks, > > > > > Alex > > > > > > > > > > On Wed, Feb 18, 2026 at 10:23 AM Nándor Kollár <[email protected] > > > > > > wrote: > > > > > > > > > > > > +1 for JSON schema, I think it is a good idea to add validation > on Helm > > > > > > values. > > > > > > > > > > > > Nandor > > > > > > > > > > > > Jean-Baptiste Onofré <[email protected]> ezt írta (időpont: 2026. > febr. > > > > > 18., > > > > > > Sze, 9:48): > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > +1 for the PR and including it in the 1.4.0-incubating release. > > > > > > > > > > > > > > Since this is a significant change, should we add a specific > note for > > > > > Helm > > > > > > > users in the release notes? > > > > > > > > > > > > > > Regards, > > > > > > > JB > > > > > > > > > > > > > > On Tue, Feb 17, 2026 at 2:47 PM Alexandre Dutra < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I recently opened a PR that introduces support for JSON > schema in > > > > the > > > > > > > > Polaris Helm chart: > > > > > > > > > > > > > > > > https://github.com/apache/polaris/pull/3759 > > > > > > > > > > > > > > > > While the feature per se is, I believe, quite consensual, > it's > > > > also a > > > > > > > > significant change. Besides, it would be released with the > upcoming > > > > > > > > 1.4.0 release, so I wanted to draw the community's attention > to it > > > > > > > > before merging the PR. > > > > > > > > > > > > > > > > If you have any comments or remarks please leave them > directly in > > > > > the PR. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > >
