All things being equal, a milestone release is only worth it if it saves us *two* regular releases: if it saves us only one regular release it will be merely "the same amount of work", as creating a milestone release is the same amount of work as creating a regular release.
So far I don't get the impression they are helping us: we have 3 pekko core patch releases *despite* having had a milestone release. I'm not optimistic promoting the milestone more would improve that significantly - and having to promote every milestone release does create additional work. I would love anything we can do to catch bugs earlier and to make releases more lightweight. While my preference is for a 1.1.0, if someone wants to RM a milestone release that's OK with me as well. Kind regards, Arnout On Mon, Nov 18, 2024 at 2:39 PM Matthew de Detrich <mdedetr...@gmail.com> wrote: > > > 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 > -- 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
