> 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 < johannes.rudo...@gmail.com> 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 > <matthew.dedetr...@aiven.io.invalid> 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 <gr...@apache.org> 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 <fannin...@gmail.com> > 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, <samb...@microsoft.com.invalid> > > > 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 <mebigfat...@gmail.com> > > > > > > Sent: Friday, April 14, 2023 2:49 PM > > > > > > To: dev@pekko.apache.org > > > > > > 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 < > nvoll...@gmail.com> > > > > > 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 <fannin...@apache.org> > > > 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: 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 > > > > > > > > > > > > > > > > > > -- > > > > 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:* matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- 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:* matthew.dedetr...@aiven.io
