Hi It has been discussed and I agree with you.
However, we consider that we need better (in terms of deliverables and quality) binary artifacts in Polaris releases. So having releases pace and cadence will start one we have a good enough release base. Let me take the lead on that because it’s major requirement during incubation period. Overall your timeline looks good to me. Our focus now should be about a fully working Polaris standalone. That’s the target for 1.0.0 that could/should be done before April. Let’s try our best effort and I propose to update the roadmap beginning of Jan with the experience on rc2. Regards JB Le jeu. 19 déc. 2024 à 21:55, Yufei Gu <flyrain...@gmail.com> a écrit : > Hi Polaris Community, > > I’d like to initiate a discussion about Polaris releases and how we can > effectively plan and execute them to align with our roadmap and broader > project goals. > Importance of a Defined Release Cadence > > Establishing a predictable release cadence will help us: > > 1. Deliver key roadmap features in a timely and structured manner. > 2. Provide clarity and transparency for contributors and users about > what to expect in upcoming versions. > 3. Align with related projects, such as Apache Iceberg, to ensure > compatibility and ease of integration. > > Current Status and Proposal > > We are currently preparing for the *0.9.0 release*, which is scheduled to > ship by *January 2025*. To maintain momentum and adapt to the fast-paced > development in the REST catalog space, I propose that we adopt a > *three-month > release cycle*. This cadence will allow us to stay agile while ensuring > regular updates. > > Additionally, this schedule aligns with Iceberg’s release cycle, which > could be beneficial if any Iceberg Spec changes require updates or > synchronization with Polaris. While syncing releases with Iceberg isn’t > mandatory, aligning them could help streamline cross-project compatibility. > Suggested Release Plan > > Using this cadence as a baseline: > > - *0.9.0*: January 2025 > - *1.0.0*: April 2025 > - *1.1.0*: July 2025 > - *1.2.0*: October 2025 ...and so on. > > It’s worth noting that *actual release dates may shift by about one month, > depending on development progress or unforeseen circumstances*. We could > adjust timelines as needed. > > I’ve created related *milestones(* > https://github.com/apache/polaris/milestones*)* in the project to reflect > these timelines. I encourage everyone to review them and tag any relevant > issues or pull requests with the appropriate versions. > Roadmap Integration > > With these milestones in place, the roadmap will naturally take shape, > driven by the features and fixes tagged in each release. Moving forward, we > can: > > - File new feature requests or bug fixes with milestone tags. > - Use these milestones as a guiding framework for project planning and > prioritization. > > ------------------------------ > > I look forward to hearing your thoughts and feedback. Related issue: > https://github.com/apache/polaris/issues/584. Let’s work together to make > Polaris’s release process efficient and impactful! > Yufei >
