Thanks, Robert, for chiming in. Production readiness is indeed a crucial point, and I'm open to any proposals that can help us achieve it. I also believe this is the right time to identify any blockers. To help with tracking, I'd suggest we add a dedicated label so we can tag related issues and PRs.
Automated releasing sounds really exciting—do we have any timeline in mind for when we might see that implemented? Yufei On Wed, Feb 12, 2025 at 10:20 AM Robert Stupp <sn...@snazy.de> wrote: > Related to the “production readiness”, we all agreed a while ago on > focusing on bugs, stability and everything around that. > I propose to really focus on those things instead of new functionality, > because features require a "rock solid” foundation. Once we have that, we > can resume work on new features. It doesn’t mean to stop on higher-level > proposals though. > > > > On 12. Feb 2025, at 08:09, Robert Stupp <sn...@snazy.de> wrote: > > > > Just want to note that there are still a lot of things to do before. > > > > WRT “production readiness”, as JB said, we need consensus on some things > _quickly_. The details can only be sorted out _with_ a consensus. April is > therefore too tight IMHO - I’d really prefer the date: “it’s ready, when > it’s ready”. Instead of committing to a release deadline, I’d really prefer > a strong commitment to security, stability and ease of use and release when > it’s really ready and _everybody_ is happy with the state. > > > > I also advocate to focus on the important things, not have any open > serious bugs or even security issues. > > > > Also noteworthy is the upcoming ASF requirement to have automated > reproducible builds/releases. I’ve already started the work for that - and > IMHO we should prefer automated releases over anything manual. > > > >> On 11. Feb 2025, at 06:58, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> > >> Hi Yufei > >> > >> Thanks for volunteering for the 1.0 release ! I've started to review > >> the legal aspect for this release as it will include binary > >> distributions. > >> The milestone scope looks good to me and makes sense. > >> > >> My only comment is about the dates. I think it's a bit early to > >> strongly commit to specific dates. Regarding 1.0, April 2025 is > >> do-able I think, assuming we are able to have consensus "quickly" on > >> some proposals (I'm thinking about persistence layer improvements for > >> instance). > >> As these proposals are discussed within the community, sometimes it > >> takes time to discuss all the points and find a consensys. > >> > >> So, if we say, "as best effort, we target 1.0 on April 25", that's > >> totally fine to me. But I'm not very comfortable with "1.0 will be > >> available on April 25". > >> > >> Just my $0.01 :) > >> > >> Regards > >> JB > >> > >> > >> On Mon, Feb 10, 2025 at 5:01 PM Yufei Gu <flyrain...@gmail.com> wrote: > >>> > >>> Hi folks, > >>> > >>> Great news—Apache Polaris 0.9 is nearly ready! Huge thanks to JB, Ryan, > >>> Russell, Robert, Tyler and everyone who contributed. Your efforts made > this > >>> first release possible. > >>> > >>> With each release, we hit a major milestone, and now it’s time to > >>> focus on *Apache > >>> Polaris 1.0*. Based on our recent community discussions (issue 584 > >>> <https://github.com/apache/polaris/issues/584>), we’re shaping 1.0 to > be > >>> the *first production-ready release*. You can check out the milestone > >>> details here <https://github.com/apache/polaris/milestone/2>. > >>> > >>> 1.0 will include all the key features you rely on—*credential vending > (S3, > >>> ADLS, GCS), RBAC, and more*—plus new capabilities like *S3-compatible > >>> storage support, policy management, and persistence layer > improvements*. > >>> We’re excited to make Polaris even more powerful for the community. > >>> > >>> I’d also like to *volunteer as the release manager* for 1.0 and look > >>> forward to working with you all to ensure a smooth launch. > >>> > >>> Thanks again for your support and contributions! > >>> > >>> > >>> Yufei > > > >
