> People can already test snapshots (and the current milestone) People are unfortunately not doing this (as is evidenced with what happened with Pekko core with the cluster concurrent race condition), and afaik the milestone is quite behind in terms of the dependencies we have updated. If a M2 milestone is done then I would advertise it in all of the relevant channels to make sure its as public as possible.
I think we need to seriously re-evaluate and have a long term view on how we do releases, both in terms of milestones (i.e. whether to use them or not) and how we make this visible. Its actually wasting more of our time rushing out full releases and then having to fix easily caught bugs amd then do another release, we are already on the 3rd patch release of pekko core because of this. On Mon, Nov 18, 2024 at 1:48 PM Arnout Engelen <enge...@apache.org> wrote: > > I think we should trust our automated tests and do a full 1.1.0 > release rather than another milestone. > > People can already test snapshots (and the current milestone), I'm not > optimistic we get significantly more testing out of releasing an M2. > The overhead of releasing a milestone is identical to the overhead of > releasing a full version. If we don't find issues, a milestone would > have caused unnecessary delay, and if we do find issues, fixing them > in a bugfix release is no more work than first having a milestone. > > While I'm in favour of splitting out the monorepo long-term, I'm not > sure we're ready for that yet. It's already tricky to find enough > people to RM and verify/vote releases, splitting out the monorepo will > make that problem worse. I'd say we should first take some more steps > to make the release process more lightweight before starting to split > repos. > > > Kind regards, > > Arnout > > > On Mon, Nov 18, 2024 at 9:29 AM Matthew de Detrich <mdedetr...@gmail.com> > wrote: > > > > Also the other reason why I would suggest a milestone rather than a > > full 1.1.x release right now is that for 1.2.x I would actually > > recommend that we start splitting out the monorepo, as is evident its > > starting to cause a lot of issues due to its big bang have to release > > everything at once. > > > > On Mon, Nov 18, 2024 at 9:03 AM Matthew de Detrich <mdedetr...@gmail.com> > > wrote: > > > > > > Can we do a milstone release as an alternative? We have been in this > > > place before and the obvious solution was a milestone release. In fact > > > with so many critical dependency updates (as you rightly mention) and > > > the fact that connectors is a massive monorepo this really does call > > > for a milestone for people to actually test that the various > > > connectors are working before doing a full release. > > > > > > On Thu, Nov 14, 2024 at 2:10 PM PJ Fanning <fannin...@apache.org> wrote: > > > > > > > > I am anxious to do a Pekko Connectors 1.1.0 release. There are > > > > significant dependency updates since 1.1.0-M1 - including CVE fixes > > > > like CVE-2024-7254. > > > > > > > > It also blocks use from releasing the 1.1.0 versions of Pekko > > > > Persistence Cassandra, Pekko Projections and Pekko Persistence R2DBC. > > > > > > > > There is no issue tracking the new auth strategy. We have no users > > > > waiting for it. > > > > > > > > We can always do a 1.2.0 or 1.1.1 release when we have the additional > > > > auth strategy. > > > > > > > > > > > > On 2024/10/16 08:57:13 Matthew de Detrich wrote: > > > > > > Would it be possible to proceed with the 1.1.0 release based on > > > > > > what's > > > > > already committed. We can always do a 1.1.1 release when your > > > > > additions are > > > > > made. > > > > > > > > > > The issue is that according to SemVer, 1.1.x is for new features and > > > > > so it > > > > > makes sense to do this in 1.1.x since it is adding an entire auth > > > > > strategy. > > > > > I already did some work on it but it is taking longer than normal, > > > > > there > > > > > isn't a need to rush through a release as people can always use the > > > > > milestone if needed (or we can do a M2 if there is a critical need > > > > > for it) > > > > > > > > > > On Tue, Oct 15, 2024 at 1:23 PM PJ Fanning <fannin...@apache.org> > > > > > wrote: > > > > > > > > > > > Hi Matthew, > > > > > > > > > > > > Would it be possible to proceed with the 1.1.0 release based on > > > > > > what's > > > > > > already committed. We can always do a 1.1.1 release when your > > > > > > additions are > > > > > > made. > > > > > > > > > > > > > > > > > > On 2024/10/09 14:05:11 Matthew de Detrich wrote: > > > > > > > So I did want to add in one feature to pekko-connectors before its > > > > > > > released, wanted to work on it this weekend. Basically its added > > > > > > > service > > > > > > > account auth compatibility to google cloud which is a problem > > > > > > > that I am > > > > > > > experiencing at work. > > > > > > > > > > > > > > Otherwise the current state of pekko-connectors looks fine to me > > > > > > > > > > > > > > On Wed, Oct 2, 2024 at 11:45 AM PJ Fanning <fannin...@apache.org> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > The last major change needed for the Pekko Connectors 1.1.0 > > > > > > > > release is > > > > > > > > to get Pekko gRPC 1.0.0 released and uptaken in the Connectors > > > > > > > > repo. > > > > > > > > The gRPC release vote is in progress. > > > > > > > > > > > > > > > > Most of the changes were in 1.1.0-M1 release [1]. Some > > > > > > > > additional > > > > > > > > changes are listed in the GitHub Milestone [2]. > > > > > > > > > > > > > > > > Does anyone have any objections to doing this RC next week? Does > > > > > > > > anyone want to take on the release manager role? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > PJ > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://pekko.apache.org/docs/pekko-connectors/1.1/release-notes/releases-1.1.html > > > > > > > > [2] https://github.com/apache/pekko-connectors/milestone/7 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > -- > Arnout Engelen > ASF Security Response > Apache Pekko PMC member, ASF Member > NixOS Committer > Independent Open Source consultant > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
