Yep, we will have to change this before this commit to be able to merge. Matthew Benedict de Detrich <[email protected]> schrieb am So., 16. Apr. 2023, 12:42:
> > We should do a real merge commit here and not do any rebasing or > squashing in this case to preserve the history and attribution as it > is. > > I don't think this is possible because we have enforced linear history for > all Pekko repos but squash/rebase does preserve attribution via the > Co-Authored tag (see > > https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors > ). > By default if you do a squash/rebase on Github's web UI it will > automatically add in the Co-Authored tags if it sees that there are > multiple commits from different authors. > > The main downside here is the loss of granularity particularly when doing a > squash (i.e. you specifically lose which commits were done by whom). > > On Sun, Apr 16, 2023 at 12:18 PM Johannes Rudolph < > [email protected]> wrote: > > > I support merging now/soon for pekko 1.0.x. It introduces some extra > > maintenance burden especially to support 2.12 and 3 at the same time. > > On the other hand, the most risky parts that the branch introduces for > > Scala 2.x support have already been merged with the move to the latest > > upstream parboiled2 version. Maintaining the branch longer will only > > become more difficult. I will hopefully have another look at the state > > of the branch next week, but I think it should be in good shape. We > > should do a real merge commit here and not do any rebasing or > > squashing in this case to preserve the history and attribution as it > > is. > > > > Johannes > > > > On Sat, Apr 15, 2023 at 11:17 AM Matthew Benedict de Detrich > > <[email protected]> wrote: > > > > > > So regarding this proposal specifically of merging the scala3 branch > into > > > pekko-http main I am all for it. The risk is low and if there are any > > > potential issues its better we find them out now rather than later > > > considering its for a 1.0.x release. There are also performance fixes > > which > > > we should reintroduce which have been removed when we moved to upstream > > > Parboiled2 > > > > > > > Granted you likely don't care all that much about what one consumer > > > thinks, > > > but i wouldn't be surprised if others are in similar situations. > > > > > > > We're in a similar situation to Dave here. Do you have an indication > > for > > > how long is left on the scala3 pekko-http support? > > > > > > I wouldn't be so rash, we actually care a lot about the users (or at > > least > > > I do). The biggest problem we are experiencing is there is a lot of > > factors > > > at play which are causing tensions. For example the original plan was > to > > > make Pekko 1.0.0 as close as possible to Akka 2.6 BSL with no > behavioural > > > changes but when then realized there were changes which would be for > the > > > better of the community. One example of such change is updating Jackson > > > (due to CVE's) which also forced us to upgrade from Scala 3.2. > > > > > > Then there are other factors at play such as Scala 3.3, there are > > extremely > > > strong arguments by many people (including Scala center/EPFL) that > Pekko > > > should target Scala 3.3 since its a LTS. The core of the bind here > really > > > is binary compatibility/stability. If we release Pekko 1.0.0 with a > > Scala 3 > > > version, we are likely going to be stuck with that version for a LOOONG > > > time considering that we made an agreement that only CVE's/critical > fixes > > > will be backported to 1.0.x branch. My personal overview of the > situation > > > is that at least technically speaking (i.e. aside from the > > > license/header/legal issues) there isn't much to do. There is a project > > > with a brief overview of what needs to be done at > > > https://github.com/orgs/apache/projects/220/views/1 so I would say as > a > > > very broad estimation there is probably 1-2 months of work which should > > > also line up well with a Scala 3.3 LTS release (that is expected this > > > month). There is also > https://github.com/apache/incubator-pekko/pull/281 > > > which we should make a discussion on, I will create a discussion thread > > for > > > this. > > > > > > On a tangential note, a discussion should probably be made about the > > > evolution of the Pekko project in general wrt binary > > > compatibility/stability. At the heart of these problems is the > > expectation > > > of extreme binary compatibility that is inherited from Akka and I think > > > there is merit in exploring whether such expectations is the healthiest > > for > > > the project in general (i.e. should they be loosened a bit?). > > > > > > On Sat, Apr 15, 2023 at 1:33 AM Greg Methvin <[email protected]> wrote: > > > > > > > I support this proposal. Scala 3 support is something most people > want > > in a > > > > Scala library these days, so having it would make the 1.0.0 release > > feel > > > > more complete, especially for new users. It would also allow library > > > > authors to publish new releases using the Scala 3 artifacts as soon > as > > > > possible. > > > > > > > > The only real concern is how much it would delay the release. If it > did > > > > cause a delay, I imagine we could put out a milestone release with > > > > everything except the Scala 3 support, to give people a chance to > start > > > > migrating earlier? > > > > > > > > > > > > > > > > On Fri, Apr 14, 2023 at 8:37 AM PJ Fanning <[email protected]> > > wrote: > > > > > > > > > incubator-pekko release is not dependent on anything in > > > > > incubator-pekko-http. The original discussion has nothing to do > with > > core > > > > > pekko. incubator-pekko will be released when they are ready. > > > > > incubator-pekko-http will be released separately, some time later > > when it > > > > > is ready. If you want to discuss incubator-pekko, please start a > new > > mail > > > > > thread. > > > > > > > > > > On Fri 14 Apr 2023, 17:27 Sam Byng, <[email protected] > > > > > > wrote: > > > > > > > > > > > We're in a similar situation to Dave here. Do you have an > > indication > > > > for > > > > > > how long is left on the scala3 pekko-http support? > > > > > > > > > > > > The positives on our side are that we don't have to wait for > pekko > > > > 1.1.0 > > > > > > to get pekko-http, and it makes further releases of connectors > etc > > > > > simpler. > > > > > > However, negatives would be the possible extension of 1.0.0 date. > > So > > > > far, > > > > > > looking at the MR it seems that adding pekko-http scala3 support > > is not > > > > > far > > > > > > off so wouldn't extend the 1.0.0 release too dramatically. > > > > > > > > > > > > -Sam > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dave Brosius <[email protected]> > > > > > > > Sent: Friday, April 14, 2023 2:49 PM > > > > > > > To: [email protected] > > > > > > > Subject: Re: [DISCUSS] adding pekko-http scala3 support now for > > > > v1.0.0 > > > > > > release > > > > > > > > > > > > > > As a future simple consumer of Apache Pekko, i'd would love > > anything > > > > > > that gets a published release sooner than later as our corporate > > > > > governance > > > > > > is on our necks about using akka (even the > last o/s variant) > > because > > > > of > > > > > > the license change. We have 1 year from the announcement (sept > > 23) to > > > > > > resolve. > > > > > > > > > > > > > > Granted you likely don't care all that much about what one > > consumer > > > > > > thinks, but i wouldn't be surprised if others are in similar > > > > situations. > > > > > > > > > > > > > > On Wed, Apr 12, 2023 at 5:54 AM Nicolas Vollmar < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > I assume overall there weren't any (major) changes to public > > APIs for > > > > > > > Scala 3, so merging it for 1.0.0 would be a small risk, but > also > > > > > > > reduce burden of maintaining the branch and allow to ship > Scala 3 > > > > > > > support across the board with 1.0.0. I'd +1 that. > > > > > > > > > > > > > > On Tue, 11 Apr 2023 at 13:26, PJ Fanning <[email protected] > > > > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I'd like to pitch the idea of just merging the pekko-http > > scala3 > > > > > > > > support to main branch when it is ready and including this in > > the > > > > > > v1.0.0 release. > > > > > > > > We have already made small-ish changes like using Parboiled > > jar and > > > > > > > > upgrading Jackson. > > > > > > > > > > > > > > > > The scala3 changes don't make significant changes to the APIs > > and > > > > it > > > > > > > feels > > > > > > > > like adding the scala3 support now would not make migration > > from > > > > > > > > Akka > > > > > > > HTTP > > > > > > > > much harder. Akka HTTP has released scala3 support (BSL > > licensed) > > > > > > > > but the release seems to have gone smoothly - without much > user > > > > > > complaint. > > > > > > > Nothing > > > > > > > > significant had to be documented about the migration to Akka > > HTTP > > > > > > > > 10.4 > > > > > > > [1]. > > > > > > > > > > > > > > > > My main reason for supporting an early merge of this is that > it > > > > will > > > > > > > > save us a whole circle of releases downstream. A scala3 > support > > > > > > > > pekko-http > > > > > > > > v1.1.0 would lead to new releases for pekko-connectors and > > other > > > > > > > downstream > > > > > > > > projects. > > > > > > > > > > > > > > > > I get that we want to make migration to v1.0.0 easy but I > don't > > > > > > > > think the > > > > > > > > scala3 changes make this significantly harder. > > > > > > > > > > > > > > > > If we had made faster progress with the v1.0.0 release then > > being > > > > > > > > conservative probably makes sense but now that we still don't > > have > > > > a > > > > > > > > release scheduled, it feels like we might be better off > > planning to > > > > > > > > get a slightly bigger v1.0.0 release done and saving > ourselves > > the > > > > > > > > hassle of having to do a v1.1.0 release for the scala3 > changes. > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc. > > > > > > > akka.io > > > > %2Fdocs%2Fakka-http%2Fcurrent%2Fmigration-guide%2Fmigration-gui > > > > > > > de-10.4.x.html%23general-notes&data=05%7C01%7Csambyng% > > > > 40microsoft.com% > > > > > > > > > > > > 7C84d3391cb35f40598c2908db3ceefd85%7C72f988bf86f141af91ab2d7cd011db47% > > > > > > > > > > > > 7C1%7C0%7C638170769415330544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > > > > > > > > > > > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > > > > > > > > > a=9kKrhjPaZVGmWaV%2FPcF%2BygzMZjd%2BzXwNpCIuQxyD%2FcY%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > - To unsubscribe, e-mail: [email protected] > For > > > > > > > > additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Matthew de Detrich > > > > > > *Aiven Deutschland GmbH* > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > *m:* +491603708037 > > > > > > *w:* aiven.io *e:* [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* [email protected] >
