> I don't see the point in a milestone release. We have received little to no feedback on milestone releases. I'm not against milestones when they are justified but I don't think we have a case here.
This is because the milestone releases have never been publicized outside of the official Apache mailing list channels which to be blunt it seems like most of the Pekko users aren't reading. Personally I have only announced non milestone releases on other public channels (twitter, reddit etc etc) and given where we are now I think this is a mistake, milestones should also be announced there so that people are aware of it and are incentivized to use it. > 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. Historically this hasn't been the case, granted as has been pointed out people are not that aware of milestones but I gave my reasons just before. Ideally people would treat -RC's seriously and properly test it before we make an actual release, but due to the short timeframe of 2 days I see that happening even less likely than someone properly testing a milestone before a future release. Also it's quite typical for software projects to use milestones like this, the suggestion isn't an outlandish one. While people are free to test snapshots, it's not the same because it's not uncommon to put broken stuff into main and then have a future PR to fix it so while using a snapshot in a production and/or pre-production system is usually not a good idea (and many organizations would completely disallow it), using a milestone is more tolerable because of the implicit understanding of a milestone (milestones still have to go through a proper release schedule and a milestone is only released at a point in time that as far as maintainers are aware is the software is in a releasable state). I don't want to block the RC of pekko connectors just for this, but I am putting it out there that anxiously rushing a release like this has caused us issues before, and the issue is not that we decide to make a release and vote on it but rather that almost all of pekko users are unaware of the existence of -RC releases. Honestly a 2 day timeframe for an -RC is way too short to do proper testing of pekko especially with our current eagerness to +1 RC's. Unless there is a CVE (which is its own process), we should have the ability to leave Pekko in a state that is at least a week so that users can do proper testing and most importantly that **users are aware of it**. Whether that is extending an RC time window to something along the lines of 1 week (which has its own issues), or using milestones or to be more prudent in allowing a +1 release (likely not going to cut it at the current stage of Pekko), I think we should properly think about this and I am also trying to be pragmatic here. On Mon, Nov 18, 2024 at 5:06 PM PJ Fanning <fannin...@gmail.com> wrote: > > I don't see the point in a milestone release. We have received little > to no feedback on milestone releases. I'm not against milestones when > they are justified but I don't think we have a case here. > > On Mon, 18 Nov 2024 at 16:22, Arnout Engelen <enge...@apache.org> wrote: > > > > 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 > > > > --------------------------------------------------------------------- > 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
