> ... we've accumulated 124 commits ... For 2.0.1, we should select only bug fixes and improvements but not new features since it is a maintenance release. There are probably new features in these commits. How about using 2.1.0 instead? If there is a need, we could cherry-pick and release 2.0.1 later on.
> How about a quarterly or 3-4 times event driven releases in one year? Time based approach usually works better then event driven -- it is easier to answer a yes/no ( in-or-out for the next release ) question for each JIRA than selecting a time to roll a new release. Tsz-Wo On Thu, Apr 10, 2025 at 8:06 PM Sammi Chen <sammic...@apache.org> wrote: > Wei-Chiu, Thanks for raising this topic. > > It would be great if the latest updates of Ozone can be released timely, so > Ozone users can benefit from that. > > I'm just a little worried about whether we have enough resouce to support > monthly release and guarantee the quality. > > How about a quarterly or 3-4 times event driven releases in one year? > > Bests, > Sammi > > > > On Fri, 11 Apr 2025 at 02:45, Wei-Chiu Chuang <weic...@apache.org> wrote: > > > As we wind down the 2.0.0 release activity, I want to start the > > conversation on the next milestone. > > > > It was just three weeks of commits, but we've accumulated 124 commits > > < > > > https://issues.apache.org/jira/issues/?filter=-1&jql=project%20%3D%20HDDS%20AND%20fixVersion%20in%20(2.1.0)%20AND%20fixVersion%20not%20in%20(2.0.0)%20AND%20status%20in%20(Resolved)%20ORDER%20BY%20priority%20DESC&startIndex=50 > > > > > in the master branch already. I would like to make regular releases > > where the diff between each release is within a reasonable delta. That > > makes the regression easier to track and vulnerable dependencies can be > > updated quicker. > > > > What do folks think? I'd like to propose a regular, monthly release, and > > keep the vote process lightweight. Even a monthly snapshot release would > be > > useful for application developers to adopt. > > > > Cheers! > > Weichiu > > >
