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