Hi Yufei, Robert, I agree regarding the release process; shipping beta features is consistent with our past practices.
As I noted in the PR, the beta flag appears to be missing. Given this and several unresolved comments, it would have been better to address the feedback before merging. There is no rush, and considering community feedback is essential. While I am very excited about the semantics feature in Polaris and leveraging Apache Ossie, we must proceed with community consensus rather than rushing. I propose that we keep the PR merged but follow up immediately to include the necessary beta wording and address the remaining concerns. Regards, JB Le jeu. 2 juil. 2026 à 21:06, Yufei Gu <[email protected]> a écrit : > Thanks, Robert. I agree that we should clarify the beta wording and review > the payload shape before considering the API stable. > > That said, I'm not sure those items need to block a release. The question, > to me, is whether we're comfortable allowing a WIP feature to evolve across > multiple releases. My understanding is that Polaris releases are not tied > to any individual feature reaching completion. Instead, we release the > project as it stands, while features continue to mature over time. We > already have precedents for this. For example, Generic Tables shipped as > experimental in 1.0.0 incubating and were only marked GA in 1.3.0 > incubating, and many other features also fit to the same pattern, like > event handling. > > Yufei > > > On Thu, Jul 2, 2026 at 10:52 AM Robert Stupp <[email protected]> wrote: > > > Since the vote was cancelled and PR #4816 merged immediately afterward, I > > do not think the public record should be read as consensus on the exact > API > > shape. I may be missing a separate consensus signal, but I think we > should > > follow up before release with explicit beta/Ossie wording, > > endpoint-discovery cleanup, and payload-shape review. > > > > Robert > > > > On Thu, Jul 2, 2026 at 7:27 AM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > Hi Yufei, > > > > > > I agree with your suggestion. We can begin the preparatory steps to > host > > > Ossie models now and proceed with the integration as soon as the Ossie > > > specification becomes available. > > > > > > Regards, > > > JB > > > > > > > > > On Tue, Jun 30, 2026 at 6:55 PM Yufei Gu <[email protected]> wrote: > > > > > > > JB, waiting for Ossie makes sense to me. That said, I'd suggest we > work > > > in > > > > parallel where possible. > > > > > > > > From my understanding, the main dependency on Ossie is the JSON > > > validator, > > > > which will arrive a bit later. Most of the other work can proceed > > > > independently in the meantime. > > > > > > > > I'm also OK moving forward without a formal vote if that's the > > preferred > > > > approach. I would keep the API explicitly in **beta** and make it > clear > > > > that we intend to transition to the Ossie specification once it > becomes > > > > available. That gives us a path to make progress now while remaining > > > > aligned with the future direction. > > > > > > > > Yufei > > > > > > > > > > > > On Tue, Jun 30, 2026 at 5:38 AM Jean-Baptiste Onofré < > [email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > It might be worth waiting for Apache Ossie to bootstrap before > > > > proceeding. > > > > > While I agree with the intent, I want to avoid duplicative work > where > > > we > > > > > implement the OSI spec first and the Apache Ossie spec as a > > follow-up. > > > > > Since the OSI spec is transitioning into the Ossie spec, and an > > initial > > > > > Apache Ossie spec release is expected soon, I suggest we pause this > > > vote. > > > > > > > > > > Additionally, I would prefer to find a consensus rather than > holding > > a > > > > > vote, as voting is typically reserved for when consensus is > difficult > > > to > > > > > reach. This vote could likely be considered a code modification > under > > > > > Apache voting guidelines ( > > > https://www.apache.org/foundation/voting.html > > > > ). > > > > > > > > > > My recommendation is to pause the vote for now and leverage Apache > > > Ossie, > > > > > which I am currently working on. > > > > > > > > > > Thoughts? > > > > > > > > > > Regards, > > > > > JB > > > > > > > > > > > > > > > On Tue, Jun 30, 2026 at 12:51 AM Yufei Gu <[email protected]> > > > wrote: > > > > > > > > > > > Beta sounds good to me. We can clarify the beta status in a > > follow-up > > > > doc > > > > > > change. > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > On Mon, Jun 29, 2026 at 3:27 PM Dmitri Bourlatchkov < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > I'd like to understand the impact of this vote better. > > > > > > > > > > > > > > Are you proposing to accept this new API without first going > > > through > > > > a > > > > > > > "beta" phase? > > > > > > > > > > > > > > I think the beta process is pretty standard for new APIs in > > Polaris > > > > > these > > > > > > > days (e.g. the Metrics API). > > > > > > > > > > > > > > Thanks, > > > > > > > Dmitri. > > > > > > > > > > > > > > On Mon, Jun 29, 2026 at 1:38 PM Yufei Gu <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > I'd like to call a vote on accepting the OSI Semantic Model > API > > > > > > > > specification proposed in PR #4816( > > > > > > > > https://github.com/apache/polaris/pull/4816) > > > > > > > > > > > > > > > > This proposal introduces the initial scaffolding for the Open > > > > > Semantic > > > > > > > > Interchange (OSI) Semantic Model API in Polaris. The primary > > goal > > > > is > > > > > to > > > > > > > > establish the REST API surface and associated specification, > > > while > > > > > > > leaving > > > > > > > > the implementation intentionally minimal. This provides a > > stable > > > > > > > foundation > > > > > > > > for future work while allowing the community to iterate on > the > > > > > > > > implementation independently. > > > > > > > > > > > > > > > > This vote will remain open for 72 hours. Please vote: > > > > > > > > > > > > > > > > [ ] +1 Accept the proposal > > > > > > > > [ ] 0 No opinion > > > > > > > > [ ] -1 Do not accept the proposal (please provide reasoning) > > > > > > > > > > > > > > > > Thanks to everyone who participated in the design discussions > > and > > > > > > > reviews. > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
