You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by PJ Fanning <fa...@apache.org> on 2023/04/11 11:26:01 UTC
[DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
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://doc.akka.io/docs/akka-http/current/migration-guide/migration-guide-10.4.x.html#general-notes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Jean-Luc Deprez <Je...@gmail.com>.
If it remains close to a "rename" drop-in replacement, getting rid of the
parallel stream could justify merging the 3 branch for 1.0.
On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> My current objection stems from how many merge commits the PR has (see
> https://github.com/apache/incubator-pekko-http/pull/130), I haven't done a
> merge in Github UI for a while but if these remain in the git log after the
> merge commit (which I believe is the case) then it would add a huge amount
> of noise to the git log. As Arnout pointed out in the PR, he can remove
> these but it would take quite a bit of work as well as potentially creating
> a regression.
>
> Also in case people are not aware, as long as a git commit references a PR
> from Github, Github will store the branch/commits from the PR indefinitely
> so you can always view the original PR to see precise commits/attribution.
> This was also pointed out earlier when we were deciding on linear history
> (fun fact, you can directly search the github UI with a commit reference
> resulting from a squash/rebase and it will show you the entire git log
> before the squash/merge).
>
> On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fa...@gmail.com> wrote:
>
> > I think it is fair to treat this as an exception and do allow a merge
> > commit for this.
> >
> > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> > >
> > > My preference is for a squash commit with the Co-Authored-Tag (which as
> > > stated before would be automatic) but that's because personally I value
> > > linear history much more strongly. In addition to the Co-Authored tag,
> > more
> > > accurate/clear attribution can also be done within the
> > > squash commit message (i.e. main/original implementation done by X,
> fixes
> > > to work with newest version done by Y etc etc).
> > >
> > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
> > > johannes.rudolph@gmail.com> wrote:
> > >
> > > > Yep, we will have to change this before this commit to be able to
> > merge.
> > > >
> > > > Matthew Benedict de Detrich <ma...@aiven.io.invalid>
> > 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 <
> > > > > johannes.rudolph@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
> > > > > > <ma...@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 <gregm@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 <
> > fanningpj@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,
> > > > <sambyng@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 <me...@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 <
> > > > > > nvollmar@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 <
> > > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > > For
> > > > > > > > > > > > additional commands, e-mail:
> dev-help@pekko.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > > For additional commands, e-mail:
> dev-help@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.dedetrich@aiven.io
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > 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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
So this has finally been completed, see
https://github.com/apache/incubator-pekko-http/pull/150. Many thanks to
everyone involved, it was a big group effort that took many years!
The PR also updated pekko-http to Scala 3.3 LTS which allows us to use the
latest version of Parboiled2 that contains many of the upstreamed
performance improvements that were originally only contained within
akka/pekko's Parboiled2 fork (see
https://github.com/apache/incubator-pekko-http/pull/150 and
https://github.com/apache/incubator-pekko-http/issues/103).
Regards
On Sun, Apr 30, 2023 at 8:00 AM Matthew Benedict de Detrich <
matthew.dedetrich@aiven.io> wrote:
> > As a compromise, I created another branch similar to Arnout's, which
> leads to the same outcome but only has a single merge to main commit
> at the end. AFAICS that will show the history as two parallel lines
> quite nicely without adding the clutter of the multiple merge commits.
>
> >
> https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1
>
> This is much better from my side, don't have any objections here.
>
> On Thu, Apr 27, 2023 at 2:49 PM Johannes Rudolph <
> johannes.rudolph@gmail.com> wrote:
>
>> We spent quite some effort to keep the extended history of the long
>> running branch, so it would be a pity to lose all that.
>>
>> As a compromise, I created another branch similar to Arnout's, which
>> leads to the same outcome but only has a single merge to main commit
>> at the end. AFAICS that will show the history as two parallel lines
>> quite nicely without adding the clutter of the multiple merge commits.
>>
>>
>> https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1
>>
>> Johannes
>>
>> On Thu, Apr 27, 2023 at 1:17 PM Arnout Engelen <en...@apache.org>
>> wrote:
>> >
>> > On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich
>> > <ma...@aiven.io.invalid> wrote:
>> > > My current objection stems from how many merge commits the PR has (see
>> > > https://github.com/apache/incubator-pekko-http/pull/130), I haven't
>> done a
>> > > merge in Github UI for a while but if these remain in the git log
>> after the
>> > > merge commit (which I believe is the case)
>> >
>> > I also believe that is the case.
>> >
>> > > then it would add a huge amount of noise to the git log.
>> > >
>> > > Also in case people are not aware, as long as a git commit references
>> a PR
>> > > from Github, Github will store the branch/commits from the PR
>> indefinitely
>> > > so you can always view the original PR to see precise
>> commits/attribution.
>> > > This was also pointed out earlier when we were deciding on linear
>> history
>> >
>> > Personally I'm not too worried about 'noise' in the git log, and think
>> > it can be helpful to have it while diagnosing issues using tools other
>> > than the GitHub web UI. That said, if it helps moving this feature
>> > forward I'm OK with having it squashed as well :).
>> >
>> > As for the general question of merging before 1.0.x: I'd say the
>> > trade-off is between:
>> > * merge now: risks incompatibility between akka-http and pekko-http
>> > 1.0.x, risks additional maintenance work to support Scala 2.12 and 3
>> > side-by-side
>> > * postpone merge: risks discovering problems with supporting 2.x and 3
>> > side-by-side later (post-1.0.x)
>> >
>> > I think it would be attractive to merge it now, to find any problems
>> > as early as possible (preferably before even releasing 1.0.x)
>> >
>> >
>> > Kind regards,
>> >
>> > Arnout
>> >
>> > > On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fa...@gmail.com>
>> wrote:
>> > >
>> > > > I think it is fair to treat this as an exception and do allow a
>> merge
>> > > > commit for this.
>> > > >
>> > > > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
>> > > > <ma...@aiven.io.invalid> wrote:
>> > > > >
>> > > > > My preference is for a squash commit with the Co-Authored-Tag
>> (which as
>> > > > > stated before would be automatic) but that's because personally I
>> value
>> > > > > linear history much more strongly. In addition to the Co-Authored
>> tag,
>> > > > more
>> > > > > accurate/clear attribution can also be done within the
>> > > > > squash commit message (i.e. main/original implementation done by
>> X, fixes
>> > > > > to work with newest version done by Y etc etc).
>> > > > >
>> > > > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
>> > > > > johannes.rudolph@gmail.com> wrote:
>> > > > >
>> > > > > > Yep, we will have to change this before this commit to be able
>> to
>> > > > merge.
>> > > > > >
>> > > > > > Matthew Benedict de Detrich <matthew.dedetrich@aiven.io
>> .invalid>
>> > > > 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 <
>> > > > > > > johannes.rudolph@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
>> > > > > > > > <ma...@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 <
>> gregm@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 <
>> > > > fanningpj@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,
>> > > > > > <sambyng@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 <me...@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 <
>> > > > > > > > nvollmar@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 <
>> > > > > > fanningpj@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-unsubscribe@pekko.apache.org
>> > > > > > > For
>> > > > > > > > > > > > > > additional commands, e-mail:
>> dev-help@pekko.apache.org
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > > > > To unsubscribe, e-mail:
>> dev-unsubscribe@pekko.apache.org
>> > > > > > > > > > > > For additional commands, e-mail:
>> dev-help@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.dedetrich@aiven.io
>> > > > > > > >
>> > > > > > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > >
>> > > > > 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.dedetrich@aiven.io
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>> >
>> >
>> >
>> > --
>> > Arnout Engelen
>> > ASF Security Response
>> > Committer on Apache Pekko
>> > Committer on NixOS
>> > Independent Open Source consultant
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > For additional commands, e-mail: dev-help@pekko.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
--
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.dedetrich@aiven.io
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> As a compromise, I created another branch similar to Arnout's, which
leads to the same outcome but only has a single merge to main commit
at the end. AFAICS that will show the history as two parallel lines
quite nicely without adding the clutter of the multiple merge commits.
>
https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1
This is much better from my side, don't have any objections here.
On Thu, Apr 27, 2023 at 2:49 PM Johannes Rudolph <jo...@gmail.com>
wrote:
> We spent quite some effort to keep the extended history of the long
> running branch, so it would be a pity to lose all that.
>
> As a compromise, I created another branch similar to Arnout's, which
> leads to the same outcome but only has a single merge to main commit
> at the end. AFAICS that will show the history as two parallel lines
> quite nicely without adding the clutter of the multiple merge commits.
>
>
> https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1
>
> Johannes
>
> On Thu, Apr 27, 2023 at 1:17 PM Arnout Engelen <en...@apache.org> wrote:
> >
> > On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> > > My current objection stems from how many merge commits the PR has (see
> > > https://github.com/apache/incubator-pekko-http/pull/130), I haven't
> done a
> > > merge in Github UI for a while but if these remain in the git log
> after the
> > > merge commit (which I believe is the case)
> >
> > I also believe that is the case.
> >
> > > then it would add a huge amount of noise to the git log.
> > >
> > > Also in case people are not aware, as long as a git commit references
> a PR
> > > from Github, Github will store the branch/commits from the PR
> indefinitely
> > > so you can always view the original PR to see precise
> commits/attribution.
> > > This was also pointed out earlier when we were deciding on linear
> history
> >
> > Personally I'm not too worried about 'noise' in the git log, and think
> > it can be helpful to have it while diagnosing issues using tools other
> > than the GitHub web UI. That said, if it helps moving this feature
> > forward I'm OK with having it squashed as well :).
> >
> > As for the general question of merging before 1.0.x: I'd say the
> > trade-off is between:
> > * merge now: risks incompatibility between akka-http and pekko-http
> > 1.0.x, risks additional maintenance work to support Scala 2.12 and 3
> > side-by-side
> > * postpone merge: risks discovering problems with supporting 2.x and 3
> > side-by-side later (post-1.0.x)
> >
> > I think it would be attractive to merge it now, to find any problems
> > as early as possible (preferably before even releasing 1.0.x)
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> > > On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fa...@gmail.com>
> wrote:
> > >
> > > > I think it is fair to treat this as an exception and do allow a merge
> > > > commit for this.
> > > >
> > > > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
> > > > <ma...@aiven.io.invalid> wrote:
> > > > >
> > > > > My preference is for a squash commit with the Co-Authored-Tag
> (which as
> > > > > stated before would be automatic) but that's because personally I
> value
> > > > > linear history much more strongly. In addition to the Co-Authored
> tag,
> > > > more
> > > > > accurate/clear attribution can also be done within the
> > > > > squash commit message (i.e. main/original implementation done by
> X, fixes
> > > > > to work with newest version done by Y etc etc).
> > > > >
> > > > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
> > > > > johannes.rudolph@gmail.com> wrote:
> > > > >
> > > > > > Yep, we will have to change this before this commit to be able to
> > > > merge.
> > > > > >
> > > > > > Matthew Benedict de Detrich <ma...@aiven.io.invalid>
> > > > 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 <
> > > > > > > johannes.rudolph@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
> > > > > > > > <ma...@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 <
> gregm@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 <
> > > > fanningpj@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,
> > > > > > <sambyng@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 <me...@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 <
> > > > > > > > nvollmar@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 <
> > > > > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > > > > For
> > > > > > > > > > > > > > additional commands, e-mail:
> dev-help@pekko.apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > > For additional commands, e-mail:
> dev-help@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.dedetrich@aiven.io
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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.dedetrich@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> >
> >
> >
> > --
> > Arnout Engelen
> > ASF Security Response
> > Committer on Apache Pekko
> > Committer on NixOS
> > Independent Open Source consultant
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Johannes Rudolph <jo...@gmail.com>.
We spent quite some effort to keep the extended history of the long
running branch, so it would be a pity to lose all that.
As a compromise, I created another branch similar to Arnout's, which
leads to the same outcome but only has a single merge to main commit
at the end. AFAICS that will show the history as two parallel lines
quite nicely without adding the clutter of the multiple merge commits.
https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1
Johannes
On Thu, Apr 27, 2023 at 1:17 PM Arnout Engelen <en...@apache.org> wrote:
>
> On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
> > My current objection stems from how many merge commits the PR has (see
> > https://github.com/apache/incubator-pekko-http/pull/130), I haven't done a
> > merge in Github UI for a while but if these remain in the git log after the
> > merge commit (which I believe is the case)
>
> I also believe that is the case.
>
> > then it would add a huge amount of noise to the git log.
> >
> > Also in case people are not aware, as long as a git commit references a PR
> > from Github, Github will store the branch/commits from the PR indefinitely
> > so you can always view the original PR to see precise commits/attribution.
> > This was also pointed out earlier when we were deciding on linear history
>
> Personally I'm not too worried about 'noise' in the git log, and think
> it can be helpful to have it while diagnosing issues using tools other
> than the GitHub web UI. That said, if it helps moving this feature
> forward I'm OK with having it squashed as well :).
>
> As for the general question of merging before 1.0.x: I'd say the
> trade-off is between:
> * merge now: risks incompatibility between akka-http and pekko-http
> 1.0.x, risks additional maintenance work to support Scala 2.12 and 3
> side-by-side
> * postpone merge: risks discovering problems with supporting 2.x and 3
> side-by-side later (post-1.0.x)
>
> I think it would be attractive to merge it now, to find any problems
> as early as possible (preferably before even releasing 1.0.x)
>
>
> Kind regards,
>
> Arnout
>
> > On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fa...@gmail.com> wrote:
> >
> > > I think it is fair to treat this as an exception and do allow a merge
> > > commit for this.
> > >
> > > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > > >
> > > > My preference is for a squash commit with the Co-Authored-Tag (which as
> > > > stated before would be automatic) but that's because personally I value
> > > > linear history much more strongly. In addition to the Co-Authored tag,
> > > more
> > > > accurate/clear attribution can also be done within the
> > > > squash commit message (i.e. main/original implementation done by X, fixes
> > > > to work with newest version done by Y etc etc).
> > > >
> > > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
> > > > johannes.rudolph@gmail.com> wrote:
> > > >
> > > > > Yep, we will have to change this before this commit to be able to
> > > merge.
> > > > >
> > > > > Matthew Benedict de Detrich <ma...@aiven.io.invalid>
> > > 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 <
> > > > > > johannes.rudolph@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
> > > > > > > <ma...@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 <
> > > fanningpj@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,
> > > > > <sambyng@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 <me...@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 <
> > > > > > > nvollmar@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 <
> > > > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > > > For
> > > > > > > > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > 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.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
>
>
> --
> Arnout Engelen
> ASF Security Response
> Committer on Apache Pekko
> Committer on NixOS
> Independent Open Source consultant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Arnout Engelen <en...@apache.org>.
On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> My current objection stems from how many merge commits the PR has (see
> https://github.com/apache/incubator-pekko-http/pull/130), I haven't done a
> merge in Github UI for a while but if these remain in the git log after the
> merge commit (which I believe is the case)
I also believe that is the case.
> then it would add a huge amount of noise to the git log.
>
> Also in case people are not aware, as long as a git commit references a PR
> from Github, Github will store the branch/commits from the PR indefinitely
> so you can always view the original PR to see precise commits/attribution.
> This was also pointed out earlier when we were deciding on linear history
Personally I'm not too worried about 'noise' in the git log, and think
it can be helpful to have it while diagnosing issues using tools other
than the GitHub web UI. That said, if it helps moving this feature
forward I'm OK with having it squashed as well :).
As for the general question of merging before 1.0.x: I'd say the
trade-off is between:
* merge now: risks incompatibility between akka-http and pekko-http
1.0.x, risks additional maintenance work to support Scala 2.12 and 3
side-by-side
* postpone merge: risks discovering problems with supporting 2.x and 3
side-by-side later (post-1.0.x)
I think it would be attractive to merge it now, to find any problems
as early as possible (preferably before even releasing 1.0.x)
Kind regards,
Arnout
> On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fa...@gmail.com> wrote:
>
> > I think it is fair to treat this as an exception and do allow a merge
> > commit for this.
> >
> > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> > >
> > > My preference is for a squash commit with the Co-Authored-Tag (which as
> > > stated before would be automatic) but that's because personally I value
> > > linear history much more strongly. In addition to the Co-Authored tag,
> > more
> > > accurate/clear attribution can also be done within the
> > > squash commit message (i.e. main/original implementation done by X, fixes
> > > to work with newest version done by Y etc etc).
> > >
> > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
> > > johannes.rudolph@gmail.com> wrote:
> > >
> > > > Yep, we will have to change this before this commit to be able to
> > merge.
> > > >
> > > > Matthew Benedict de Detrich <ma...@aiven.io.invalid>
> > 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 <
> > > > > johannes.rudolph@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
> > > > > > <ma...@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 <
> > fanningpj@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,
> > > > <sambyng@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 <me...@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 <
> > > > > > nvollmar@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 <
> > > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > > For
> > > > > > > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > 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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
--
Arnout Engelen
ASF Security Response
Committer on Apache Pekko
Committer on NixOS
Independent Open Source consultant
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
My current objection stems from how many merge commits the PR has (see
https://github.com/apache/incubator-pekko-http/pull/130), I haven't done a
merge in Github UI for a while but if these remain in the git log after the
merge commit (which I believe is the case) then it would add a huge amount
of noise to the git log. As Arnout pointed out in the PR, he can remove
these but it would take quite a bit of work as well as potentially creating
a regression.
Also in case people are not aware, as long as a git commit references a PR
from Github, Github will store the branch/commits from the PR indefinitely
so you can always view the original PR to see precise commits/attribution.
This was also pointed out earlier when we were deciding on linear history
(fun fact, you can directly search the github UI with a commit reference
resulting from a squash/rebase and it will show you the entire git log
before the squash/merge).
On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fa...@gmail.com> wrote:
> I think it is fair to treat this as an exception and do allow a merge
> commit for this.
>
> On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > My preference is for a squash commit with the Co-Authored-Tag (which as
> > stated before would be automatic) but that's because personally I value
> > linear history much more strongly. In addition to the Co-Authored tag,
> more
> > accurate/clear attribution can also be done within the
> > squash commit message (i.e. main/original implementation done by X, fixes
> > to work with newest version done by Y etc etc).
> >
> > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
> > johannes.rudolph@gmail.com> wrote:
> >
> > > Yep, we will have to change this before this commit to be able to
> merge.
> > >
> > > Matthew Benedict de Detrich <ma...@aiven.io.invalid>
> 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 <
> > > > johannes.rudolph@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
> > > > > <ma...@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 <
> fanningpj@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,
> > > <sambyng@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 <me...@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 <
> > > > > nvollmar@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 <
> > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > For
> > > > > > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > >
> > >
> >
> >
> > --
> >
> > 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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by PJ Fanning <fa...@gmail.com>.
I think it is fair to treat this as an exception and do allow a merge
commit for this.
On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
>
> My preference is for a squash commit with the Co-Authored-Tag (which as
> stated before would be automatic) but that's because personally I value
> linear history much more strongly. In addition to the Co-Authored tag, more
> accurate/clear attribution can also be done within the
> squash commit message (i.e. main/original implementation done by X, fixes
> to work with newest version done by Y etc etc).
>
> On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
> johannes.rudolph@gmail.com> wrote:
>
> > Yep, we will have to change this before this commit to be able to merge.
> >
> > Matthew Benedict de Detrich <ma...@aiven.io.invalid> 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 <
> > > johannes.rudolph@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
> > > > <ma...@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 <fa...@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,
> > <sambyng@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 <me...@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 <
> > > > nvollmar@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 <
> > fanningpj@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-unsubscribe@pekko.apache.org
> > > For
> > > > > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > >
> >
>
>
> --
>
> 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.dedetrich@aiven.io
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
My preference is for a squash commit with the Co-Authored-Tag (which as
stated before would be automatic) but that's because personally I value
linear history much more strongly. In addition to the Co-Authored tag, more
accurate/clear attribution can also be done within the
squash commit message (i.e. main/original implementation done by X, fixes
to work with newest version done by Y etc etc).
On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph <
johannes.rudolph@gmail.com> wrote:
> Yep, we will have to change this before this commit to be able to merge.
>
> Matthew Benedict de Detrich <ma...@aiven.io.invalid> 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 <
> > johannes.rudolph@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
> > > <ma...@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 <fa...@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,
> <sambyng@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 <me...@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 <
> > > nvollmar@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 <
> fanningpj@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-unsubscribe@pekko.apache.org
> > For
> > > > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> >
>
--
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.dedetrich@aiven.io
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Johannes Rudolph <jo...@gmail.com>.
Yep, we will have to change this before this commit to be able to merge.
Matthew Benedict de Detrich <ma...@aiven.io.invalid> 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 <
> johannes.rudolph@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
> > <ma...@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 <fa...@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, <sambyng@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 <me...@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 <
> > nvollmar@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 <fanningpj@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-unsubscribe@pekko.apache.org
> For
> > > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> 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.rudolph@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
> <ma...@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 <fa...@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, <sa...@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 <me...@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 <
> nvollmar@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 <fa...@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-unsubscribe@pekko.apache.org For
> > > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Johannes Rudolph <jo...@gmail.com>.
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
<ma...@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 <fa...@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, <sa...@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 <me...@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 <nv...@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 <fa...@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-unsubscribe@pekko.apache.org For
> > > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
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 <fa...@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, <sa...@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 <me...@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 <nv...@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 <fa...@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-unsubscribe@pekko.apache.org For
> > > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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.dedetrich@aiven.io
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Greg Methvin <gr...@apache.org>.
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 <fa...@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, <sa...@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 <me...@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 <nv...@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 <fa...@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-unsubscribe@pekko.apache.org For
> > > > additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
>
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by PJ Fanning <fa...@gmail.com>.
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, <sa...@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 <me...@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 <nv...@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 <fa...@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-unsubscribe@pekko.apache.org For
> > > additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Sam Byng <sa...@microsoft.com.INVALID>.
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 <me...@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 <nv...@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 <fa...@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-unsubscribe@pekko.apache.org For
> > additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Dave Brosius <me...@gmail.com>.
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 <nv...@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 <fa...@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://doc.akka.io/docs/akka-http/current/migration-guide/migration-guide-10.4.x.html#general-notes
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
Re: [DISCUSS] adding pekko-http scala3 support now for v1.0.0 release
Posted by Nicolas Vollmar <nv...@gmail.com>.
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 <fa...@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://doc.akka.io/docs/akka-http/current/migration-guide/migration-guide-10.4.x.html#general-notes
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>