I like the idea of a label to identify the blockers for 1.0.0 (or maybe just using milestones could be enough).
For automatic release, it’s clearly on path. I don’t consider this required for 1.0.0 (1.0.0 release can be done manually) but good to have. Thanks ! Regards JB Le mer. 12 févr. 2025 à 14:03, Yufei Gu <flyrain...@gmail.com> a écrit : > 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 > > > > > > > >
