You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by Matthew de Detrich <ma...@aiven.io.INVALID> on 2024/03/07 14:14:14 UTC
[DISCUSS] Pekko Persistence JDBC 1.1.0-M1 release
Now that Scala 3 support has been merged with the release of
Slick 3.5.0[1] I think it's a good time to make a M1 release given that
the changes in Slick 3.5.0 were so extensive, just to make sure everything
is working as intended and a milestone release should signal to the
community to "please use it to test it".
Since scala steward support is merged[2] doing the milestone when
the update PR's are created early next week seems like a good candidate
in terms of time. There also is a question of whether we should also
fix the issue with the latest oracle version[2] for the M1.
Thoughts?
1: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
3: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by PJ Fanning <fa...@apache.org>.
I don't know much about the Pekko Persistence implementations. Is the
'revision' support something that we should try to fix for 1.1.0 and
if so, is it important enough for 1.1.0-M1?
https://github.com/apache/incubator-pekko-persistence-jdbc/issues/30
On Mon, 11 Mar 2024 at 12:37, Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
>
> Just pointing out that we are having a discussion regarding Scala 3/Slick
> 3.5.0 support
> in pekko-projection-slick that adds another argument for releasing a M1 of
> pekko-persistence-jdbc
> at
> https://github.com/apache/incubator-pekko-projection/issues/110#issuecomment-1988228503
>
> On Sun, Mar 10, 2024 at 11:06 AM Matthew de Detrich <
> matthew.dedetrich@aiven.io> wrote:
>
> > > I would prefer not to release while it is using a snapshot version of
> > our paradox plugin. Let's get the release completed for the paradox
> > plugin first.
> >
> > Okay sure, lets wait for that
> >
> > On Sun, Mar 10, 2024 at 11:05 AM PJ Fanning <fa...@apache.org> wrote:
> >
> >> I would prefer not to release while it is using a snapshot version of
> >> our paradox plugin. Let's get the release completed for the paradox
> >> plugin first.
> >>
> >> On Sun, 10 Mar 2024 at 11:03, Matthew de Detrich
> >> <ma...@aiven.io.invalid> wrote:
> >> >
> >> > With all of the PR's from Scala Steward merged, I would advocate for an
> >> M1
> >> > release tomorrow
> >> > unless there is a strong objection otherwise.
> >> >
> >> > Not going to rehash in details the reasons why for an M1 rather than a
> >> full
> >> > release, but we have another
> >> > driver mssql which also may require breaking changes in the future[1]
> >> ontop
> >> > of oracle[2] and since
> >> > I would like to ideally make postgres-persistence-jdbc SemVer
> >> compatible it
> >> > makes sense to make
> >> > the M1 release now, also to be fair to people waiting for Slick 3.5.x
> >> > support.
> >> >
> >> > Hopefully with an M1 release, more people will actually use
> >> > pekko-persistence-jdbc so that we can
> >> > get some contributions for the oracle/mssql drivers.
> >> >
> >> > On Thu, Mar 7, 2024 at 4:27 PM Matthew de Detrich <
> >> > matthew.dedetrich@aiven.io> wrote:
> >> >
> >> > > > pekko-persistence-jdbc is not downloaded very often from Maven
> >> > > Central. I doubt whether us releasing a milestone release will help
> >> > > Slick testing much.
> >> > >
> >> > > Well that can also be because for a lot of users the current
> >> > > pekko-persistence-jdbc wasn't really usable outside of migrating
> >> > > from akka to pekko because it was stuck on a really old version of
> >> Slick
> >> > > (3.3.x).
> >> > >
> >> > > In other words if anything the current low download rate from Maven
> >> central
> >> > > can be indicating that in fact users were in fact waiting for an RC
> >> style
> >> > > of release
> >> > > to test/use Slick 3.5.x and there definitely was multiple people in
> >> the
> >> > > community asking
> >> > > for it (even in the PR itself[1]!)
> >> > >
> >> > > > Regarding Oracle testing, it would be good to work out what is going
> >> > > on with that strange region error. If we have any Oracle experts, it
> >> > > it would be great to get this sorted out.
> >> > >
> >> > > Agreed, and from the sounds of the PR it may break the API? If so,
> >> hence
> >> > > another reason for an M1 now in case this may happen.
> >> > >
> >> > > 1:
> >> > >
> >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
> >> > >
> >> > > On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com>
> >> wrote:
> >> > >
> >> > >> pekko-persistence-jdbc is not downloaded very often from Maven
> >> > >> Central. I doubt whether us releasing a milestone release will help
> >> > >> Slick testing much.
> >> > >>
> >> > >> Regarding Oracle testing, it would be good to work out what is going
> >> > >> on with that strange region error. If we have any Oracle experts, it
> >> > >> would be great to get this sorted out.
> >> > >>
> >> > >> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
> >> > >> <ma...@aiven.io.invalid> wrote:
> >> > >> >
> >> > >> > > I would favour just making a full 1.1.0 release. I don't see the
> >> > >> > benefit of having a milestone release.
> >> > >> >
> >> > >> > It was requested for us to do an RC so the community could
> >> properly test
> >> > >> > Slick 3.5.0-RC5 but we didn't do this because we want our projects
> >> to
> >> > >> > always be in a releasable state[1] and hence I suspect that no one
> >> > >> really
> >> > >> > tested
> >> > >> > pekko-persistence-jdbc because it wasn't really announced
> >> anywhere. The
> >> > >> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I
> >> think
> >> > >> it's
> >> > >> > warranted
> >> > >> > to be more prudent here.
> >> > >> >
> >> > >> > Also we need to make sure that the project works properly with
> >> > >> pekko-core
> >> > >> > 1.1.x
> >> > >> > along with all of the inlining and other changes and pekko-core
> >> 1.1.x
> >> > >> hasn't
> >> > >> > even been released yet.
> >> > >> >
> >> > >> > Support for the latest oracle[2] is also something that we may
> >> want to
> >> > >> add
> >> > >> > after M1,
> >> > >> > this seems to be undecided?
> >> > >> >
> >> > >> > 1:
> >> > >>
> >> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> >> > >> > 2:
> >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >> > >> >
> >> > >> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com>
> >> wrote:
> >> > >> >
> >> > >> > > I would favour just making a full 1.1.0 release. I don't see the
> >> > >> > > benefit of having a milestone release.
> >> > >> > >
> >> > >> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> >> > >> > > <ma...@aiven.io.invalid> wrote:
> >> > >> > > >
> >> > >> > > > Now that Scala 3 support has been merged with the release of
> >> > >> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release
> >> given
> >> > >> that
> >> > >> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> >> > >> > > everything
> >> > >> > > > is working as intended and a milestone release should signal
> >> to the
> >> > >> > > > community to "please use it to test it".
> >> > >> > > >
> >> > >> > > > Since scala steward support is merged[2] doing the milestone
> >> when
> >> > >> > > > the update PR's are created early next week seems like a good
> >> > >> candidate
> >> > >> > > > in terms of time. There also is a question of whether we
> >> should also
> >> > >> > > > fix the issue with the latest oracle version[2] for the M1.
> >> > >> > > >
> >> > >> > > > Thoughts?
> >> > >> > > >
> >> > >> > > > 1:
> >> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> >> > >> > > > 2:
> >> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> >> > >> > > > 3:
> >> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >> > >> > > >
> >> > >> > > > --
> >> > >> > > >
> >> > >> > > > Matthew de Detrich
> >> > >> > > >
> >> > >> > > > *Aiven Deutschland GmbH*
> >> > >> > > >
> >> > >> > > > Immanuelkirchstraße 26, 10405 Berlin
> >> > >> > > >
> >> > >> > > > Alexanderufer 3-7, 10117 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
> >> > >> >
> >> > >> > Alexanderufer 3-7, 10117 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
> >> > >
> >> > > Alexanderufer 3-7, 10117 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
> >> >
> >> > Alexanderufer 3-7, 10117 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
> >
> > Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
Just pointing out that we are having a discussion regarding Scala 3/Slick
3.5.0 support
in pekko-projection-slick that adds another argument for releasing a M1 of
pekko-persistence-jdbc
at
https://github.com/apache/incubator-pekko-projection/issues/110#issuecomment-1988228503
On Sun, Mar 10, 2024 at 11:06 AM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> > I would prefer not to release while it is using a snapshot version of
> our paradox plugin. Let's get the release completed for the paradox
> plugin first.
>
> Okay sure, lets wait for that
>
> On Sun, Mar 10, 2024 at 11:05 AM PJ Fanning <fa...@apache.org> wrote:
>
>> I would prefer not to release while it is using a snapshot version of
>> our paradox plugin. Let's get the release completed for the paradox
>> plugin first.
>>
>> On Sun, 10 Mar 2024 at 11:03, Matthew de Detrich
>> <ma...@aiven.io.invalid> wrote:
>> >
>> > With all of the PR's from Scala Steward merged, I would advocate for an
>> M1
>> > release tomorrow
>> > unless there is a strong objection otherwise.
>> >
>> > Not going to rehash in details the reasons why for an M1 rather than a
>> full
>> > release, but we have another
>> > driver mssql which also may require breaking changes in the future[1]
>> ontop
>> > of oracle[2] and since
>> > I would like to ideally make postgres-persistence-jdbc SemVer
>> compatible it
>> > makes sense to make
>> > the M1 release now, also to be fair to people waiting for Slick 3.5.x
>> > support.
>> >
>> > Hopefully with an M1 release, more people will actually use
>> > pekko-persistence-jdbc so that we can
>> > get some contributions for the oracle/mssql drivers.
>> >
>> > On Thu, Mar 7, 2024 at 4:27 PM Matthew de Detrich <
>> > matthew.dedetrich@aiven.io> wrote:
>> >
>> > > > pekko-persistence-jdbc is not downloaded very often from Maven
>> > > Central. I doubt whether us releasing a milestone release will help
>> > > Slick testing much.
>> > >
>> > > Well that can also be because for a lot of users the current
>> > > pekko-persistence-jdbc wasn't really usable outside of migrating
>> > > from akka to pekko because it was stuck on a really old version of
>> Slick
>> > > (3.3.x).
>> > >
>> > > In other words if anything the current low download rate from Maven
>> central
>> > > can be indicating that in fact users were in fact waiting for an RC
>> style
>> > > of release
>> > > to test/use Slick 3.5.x and there definitely was multiple people in
>> the
>> > > community asking
>> > > for it (even in the PR itself[1]!)
>> > >
>> > > > Regarding Oracle testing, it would be good to work out what is going
>> > > on with that strange region error. If we have any Oracle experts, it
>> > > it would be great to get this sorted out.
>> > >
>> > > Agreed, and from the sounds of the PR it may break the API? If so,
>> hence
>> > > another reason for an M1 now in case this may happen.
>> > >
>> > > 1:
>> > >
>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
>> > >
>> > > On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com>
>> wrote:
>> > >
>> > >> pekko-persistence-jdbc is not downloaded very often from Maven
>> > >> Central. I doubt whether us releasing a milestone release will help
>> > >> Slick testing much.
>> > >>
>> > >> Regarding Oracle testing, it would be good to work out what is going
>> > >> on with that strange region error. If we have any Oracle experts, it
>> > >> would be great to get this sorted out.
>> > >>
>> > >> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
>> > >> <ma...@aiven.io.invalid> wrote:
>> > >> >
>> > >> > > I would favour just making a full 1.1.0 release. I don't see the
>> > >> > benefit of having a milestone release.
>> > >> >
>> > >> > It was requested for us to do an RC so the community could
>> properly test
>> > >> > Slick 3.5.0-RC5 but we didn't do this because we want our projects
>> to
>> > >> > always be in a releasable state[1] and hence I suspect that no one
>> > >> really
>> > >> > tested
>> > >> > pekko-persistence-jdbc because it wasn't really announced
>> anywhere. The
>> > >> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I
>> think
>> > >> it's
>> > >> > warranted
>> > >> > to be more prudent here.
>> > >> >
>> > >> > Also we need to make sure that the project works properly with
>> > >> pekko-core
>> > >> > 1.1.x
>> > >> > along with all of the inlining and other changes and pekko-core
>> 1.1.x
>> > >> hasn't
>> > >> > even been released yet.
>> > >> >
>> > >> > Support for the latest oracle[2] is also something that we may
>> want to
>> > >> add
>> > >> > after M1,
>> > >> > this seems to be undecided?
>> > >> >
>> > >> > 1:
>> > >>
>> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
>> > >> > 2:
>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>> > >> >
>> > >> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com>
>> wrote:
>> > >> >
>> > >> > > I would favour just making a full 1.1.0 release. I don't see the
>> > >> > > benefit of having a milestone release.
>> > >> > >
>> > >> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
>> > >> > > <ma...@aiven.io.invalid> wrote:
>> > >> > > >
>> > >> > > > Now that Scala 3 support has been merged with the release of
>> > >> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release
>> given
>> > >> that
>> > >> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
>> > >> > > everything
>> > >> > > > is working as intended and a milestone release should signal
>> to the
>> > >> > > > community to "please use it to test it".
>> > >> > > >
>> > >> > > > Since scala steward support is merged[2] doing the milestone
>> when
>> > >> > > > the update PR's are created early next week seems like a good
>> > >> candidate
>> > >> > > > in terms of time. There also is a question of whether we
>> should also
>> > >> > > > fix the issue with the latest oracle version[2] for the M1.
>> > >> > > >
>> > >> > > > Thoughts?
>> > >> > > >
>> > >> > > > 1:
>> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
>> > >> > > > 2:
>> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
>> > >> > > > 3:
>> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>> > >> > > >
>> > >> > > > --
>> > >> > > >
>> > >> > > > Matthew de Detrich
>> > >> > > >
>> > >> > > > *Aiven Deutschland GmbH*
>> > >> > > >
>> > >> > > > Immanuelkirchstraße 26, 10405 Berlin
>> > >> > > >
>> > >> > > > Alexanderufer 3-7, 10117 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
>> > >> >
>> > >> > Alexanderufer 3-7, 10117 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
>> > >
>> > > Alexanderufer 3-7, 10117 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
>> >
>> > Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> I would prefer not to release while it is using a snapshot version of
our paradox plugin. Let's get the release completed for the paradox
plugin first.
Okay sure, lets wait for that
On Sun, Mar 10, 2024 at 11:05 AM PJ Fanning <fa...@apache.org> wrote:
> I would prefer not to release while it is using a snapshot version of
> our paradox plugin. Let's get the release completed for the paradox
> plugin first.
>
> On Sun, 10 Mar 2024 at 11:03, Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > With all of the PR's from Scala Steward merged, I would advocate for an
> M1
> > release tomorrow
> > unless there is a strong objection otherwise.
> >
> > Not going to rehash in details the reasons why for an M1 rather than a
> full
> > release, but we have another
> > driver mssql which also may require breaking changes in the future[1]
> ontop
> > of oracle[2] and since
> > I would like to ideally make postgres-persistence-jdbc SemVer compatible
> it
> > makes sense to make
> > the M1 release now, also to be fair to people waiting for Slick 3.5.x
> > support.
> >
> > Hopefully with an M1 release, more people will actually use
> > pekko-persistence-jdbc so that we can
> > get some contributions for the oracle/mssql drivers.
> >
> > On Thu, Mar 7, 2024 at 4:27 PM Matthew de Detrich <
> > matthew.dedetrich@aiven.io> wrote:
> >
> > > > pekko-persistence-jdbc is not downloaded very often from Maven
> > > Central. I doubt whether us releasing a milestone release will help
> > > Slick testing much.
> > >
> > > Well that can also be because for a lot of users the current
> > > pekko-persistence-jdbc wasn't really usable outside of migrating
> > > from akka to pekko because it was stuck on a really old version of
> Slick
> > > (3.3.x).
> > >
> > > In other words if anything the current low download rate from Maven
> central
> > > can be indicating that in fact users were in fact waiting for an RC
> style
> > > of release
> > > to test/use Slick 3.5.x and there definitely was multiple people in the
> > > community asking
> > > for it (even in the PR itself[1]!)
> > >
> > > > Regarding Oracle testing, it would be good to work out what is going
> > > on with that strange region error. If we have any Oracle experts, it
> > > it would be great to get this sorted out.
> > >
> > > Agreed, and from the sounds of the PR it may break the API? If so,
> hence
> > > another reason for an M1 now in case this may happen.
> > >
> > > 1:
> > >
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
> > >
> > > On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com> wrote:
> > >
> > >> pekko-persistence-jdbc is not downloaded very often from Maven
> > >> Central. I doubt whether us releasing a milestone release will help
> > >> Slick testing much.
> > >>
> > >> Regarding Oracle testing, it would be good to work out what is going
> > >> on with that strange region error. If we have any Oracle experts, it
> > >> would be great to get this sorted out.
> > >>
> > >> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
> > >> <ma...@aiven.io.invalid> wrote:
> > >> >
> > >> > > I would favour just making a full 1.1.0 release. I don't see the
> > >> > benefit of having a milestone release.
> > >> >
> > >> > It was requested for us to do an RC so the community could properly
> test
> > >> > Slick 3.5.0-RC5 but we didn't do this because we want our projects
> to
> > >> > always be in a releasable state[1] and hence I suspect that no one
> > >> really
> > >> > tested
> > >> > pekko-persistence-jdbc because it wasn't really announced anywhere.
> The
> > >> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I
> think
> > >> it's
> > >> > warranted
> > >> > to be more prudent here.
> > >> >
> > >> > Also we need to make sure that the project works properly with
> > >> pekko-core
> > >> > 1.1.x
> > >> > along with all of the inlining and other changes and pekko-core
> 1.1.x
> > >> hasn't
> > >> > even been released yet.
> > >> >
> > >> > Support for the latest oracle[2] is also something that we may want
> to
> > >> add
> > >> > after M1,
> > >> > this seems to be undecided?
> > >> >
> > >> > 1:
> > >>
> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > >> > 2:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > >> >
> > >> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com>
> wrote:
> > >> >
> > >> > > I would favour just making a full 1.1.0 release. I don't see the
> > >> > > benefit of having a milestone release.
> > >> > >
> > >> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > >> > > <ma...@aiven.io.invalid> wrote:
> > >> > > >
> > >> > > > Now that Scala 3 support has been merged with the release of
> > >> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release
> given
> > >> that
> > >> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > >> > > everything
> > >> > > > is working as intended and a milestone release should signal to
> the
> > >> > > > community to "please use it to test it".
> > >> > > >
> > >> > > > Since scala steward support is merged[2] doing the milestone
> when
> > >> > > > the update PR's are created early next week seems like a good
> > >> candidate
> > >> > > > in terms of time. There also is a question of whether we should
> also
> > >> > > > fix the issue with the latest oracle version[2] for the M1.
> > >> > > >
> > >> > > > Thoughts?
> > >> > > >
> > >> > > > 1:
> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > >> > > > 2:
> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > >> > > > 3:
> > >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > >> > > >
> > >> > > > --
> > >> > > >
> > >> > > > Matthew de Detrich
> > >> > > >
> > >> > > > *Aiven Deutschland GmbH*
> > >> > > >
> > >> > > > Immanuelkirchstraße 26, 10405 Berlin
> > >> > > >
> > >> > > > Alexanderufer 3-7, 10117 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
> > >> >
> > >> > Alexanderufer 3-7, 10117 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
> > >
> > > Alexanderufer 3-7, 10117 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
> >
> > Alexanderufer 3-7, 10117 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
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by PJ Fanning <fa...@apache.org>.
I would prefer not to release while it is using a snapshot version of
our paradox plugin. Let's get the release completed for the paradox
plugin first.
On Sun, 10 Mar 2024 at 11:03, Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
>
> With all of the PR's from Scala Steward merged, I would advocate for an M1
> release tomorrow
> unless there is a strong objection otherwise.
>
> Not going to rehash in details the reasons why for an M1 rather than a full
> release, but we have another
> driver mssql which also may require breaking changes in the future[1] ontop
> of oracle[2] and since
> I would like to ideally make postgres-persistence-jdbc SemVer compatible it
> makes sense to make
> the M1 release now, also to be fair to people waiting for Slick 3.5.x
> support.
>
> Hopefully with an M1 release, more people will actually use
> pekko-persistence-jdbc so that we can
> get some contributions for the oracle/mssql drivers.
>
> On Thu, Mar 7, 2024 at 4:27 PM Matthew de Detrich <
> matthew.dedetrich@aiven.io> wrote:
>
> > > pekko-persistence-jdbc is not downloaded very often from Maven
> > Central. I doubt whether us releasing a milestone release will help
> > Slick testing much.
> >
> > Well that can also be because for a lot of users the current
> > pekko-persistence-jdbc wasn't really usable outside of migrating
> > from akka to pekko because it was stuck on a really old version of Slick
> > (3.3.x).
> >
> > In other words if anything the current low download rate from Maven central
> > can be indicating that in fact users were in fact waiting for an RC style
> > of release
> > to test/use Slick 3.5.x and there definitely was multiple people in the
> > community asking
> > for it (even in the PR itself[1]!)
> >
> > > Regarding Oracle testing, it would be good to work out what is going
> > on with that strange region error. If we have any Oracle experts, it
> > it would be great to get this sorted out.
> >
> > Agreed, and from the sounds of the PR it may break the API? If so, hence
> > another reason for an M1 now in case this may happen.
> >
> > 1:
> > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
> >
> > On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com> wrote:
> >
> >> pekko-persistence-jdbc is not downloaded very often from Maven
> >> Central. I doubt whether us releasing a milestone release will help
> >> Slick testing much.
> >>
> >> Regarding Oracle testing, it would be good to work out what is going
> >> on with that strange region error. If we have any Oracle experts, it
> >> would be great to get this sorted out.
> >>
> >> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
> >> <ma...@aiven.io.invalid> wrote:
> >> >
> >> > > I would favour just making a full 1.1.0 release. I don't see the
> >> > benefit of having a milestone release.
> >> >
> >> > It was requested for us to do an RC so the community could properly test
> >> > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> >> > always be in a releasable state[1] and hence I suspect that no one
> >> really
> >> > tested
> >> > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> >> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
> >> it's
> >> > warranted
> >> > to be more prudent here.
> >> >
> >> > Also we need to make sure that the project works properly with
> >> pekko-core
> >> > 1.1.x
> >> > along with all of the inlining and other changes and pekko-core 1.1.x
> >> hasn't
> >> > even been released yet.
> >> >
> >> > Support for the latest oracle[2] is also something that we may want to
> >> add
> >> > after M1,
> >> > this seems to be undecided?
> >> >
> >> > 1:
> >> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> >> > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >> >
> >> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> >> >
> >> > > I would favour just making a full 1.1.0 release. I don't see the
> >> > > benefit of having a milestone release.
> >> > >
> >> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> >> > > <ma...@aiven.io.invalid> wrote:
> >> > > >
> >> > > > Now that Scala 3 support has been merged with the release of
> >> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
> >> that
> >> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> >> > > everything
> >> > > > is working as intended and a milestone release should signal to the
> >> > > > community to "please use it to test it".
> >> > > >
> >> > > > Since scala steward support is merged[2] doing the milestone when
> >> > > > the update PR's are created early next week seems like a good
> >> candidate
> >> > > > in terms of time. There also is a question of whether we should also
> >> > > > fix the issue with the latest oracle version[2] for the M1.
> >> > > >
> >> > > > Thoughts?
> >> > > >
> >> > > > 1:
> >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> >> > > > 2:
> >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> >> > > > 3:
> >> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >> > > >
> >> > > > --
> >> > > >
> >> > > > Matthew de Detrich
> >> > > >
> >> > > > *Aiven Deutschland GmbH*
> >> > > >
> >> > > > Immanuelkirchstraße 26, 10405 Berlin
> >> > > >
> >> > > > Alexanderufer 3-7, 10117 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
> >> >
> >> > Alexanderufer 3-7, 10117 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
> >
> > Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
1: https://github.com/apache/incubator-pekko-persistence-jdbc/issues/113
2: https://github.com/apache/incubator-pekko-persistence-jdbc/issues/112
On Sun, Mar 10, 2024 at 11:00 AM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> With all of the PR's from Scala Steward merged, I would advocate for an M1
> release tomorrow
> unless there is a strong objection otherwise.
>
> Not going to rehash in details the reasons why for an M1 rather than a
> full release, but we have another
> driver mssql which also may require breaking changes in the future[1]
> ontop of oracle[2] and since
> I would like to ideally make postgres-persistence-jdbc SemVer compatible
> it makes sense to make
> the M1 release now, also to be fair to people waiting for Slick 3.5.x
> support.
>
> Hopefully with an M1 release, more people will actually use
> pekko-persistence-jdbc so that we can
> get some contributions for the oracle/mssql drivers.
>
> On Thu, Mar 7, 2024 at 4:27 PM Matthew de Detrich <
> matthew.dedetrich@aiven.io> wrote:
>
>> > pekko-persistence-jdbc is not downloaded very often from Maven
>> Central. I doubt whether us releasing a milestone release will help
>> Slick testing much.
>>
>> Well that can also be because for a lot of users the current
>> pekko-persistence-jdbc wasn't really usable outside of migrating
>> from akka to pekko because it was stuck on a really old version of Slick
>> (3.3.x).
>>
>> In other words if anything the current low download rate from Maven
>> central
>> can be indicating that in fact users were in fact waiting for an RC style
>> of release
>> to test/use Slick 3.5.x and there definitely was multiple people in the
>> community asking
>> for it (even in the PR itself[1]!)
>>
>> > Regarding Oracle testing, it would be good to work out what is going
>> on with that strange region error. If we have any Oracle experts, it
>> it would be great to get this sorted out.
>>
>> Agreed, and from the sounds of the PR it may break the API? If so, hence
>> another reason for an M1 now in case this may happen.
>>
>> 1:
>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
>>
>> On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com> wrote:
>>
>>> pekko-persistence-jdbc is not downloaded very often from Maven
>>> Central. I doubt whether us releasing a milestone release will help
>>> Slick testing much.
>>>
>>> Regarding Oracle testing, it would be good to work out what is going
>>> on with that strange region error. If we have any Oracle experts, it
>>> would be great to get this sorted out.
>>>
>>> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
>>> <ma...@aiven.io.invalid> wrote:
>>> >
>>> > > I would favour just making a full 1.1.0 release. I don't see the
>>> > benefit of having a milestone release.
>>> >
>>> > It was requested for us to do an RC so the community could properly
>>> test
>>> > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
>>> > always be in a releasable state[1] and hence I suspect that no one
>>> really
>>> > tested
>>> > pekko-persistence-jdbc because it wasn't really announced anywhere. The
>>> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
>>> it's
>>> > warranted
>>> > to be more prudent here.
>>> >
>>> > Also we need to make sure that the project works properly with
>>> pekko-core
>>> > 1.1.x
>>> > along with all of the inlining and other changes and pekko-core 1.1.x
>>> hasn't
>>> > even been released yet.
>>> >
>>> > Support for the latest oracle[2] is also something that we may want to
>>> add
>>> > after M1,
>>> > this seems to be undecided?
>>> >
>>> > 1:
>>> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
>>> > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>>> >
>>> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
>>> >
>>> > > I would favour just making a full 1.1.0 release. I don't see the
>>> > > benefit of having a milestone release.
>>> > >
>>> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
>>> > > <ma...@aiven.io.invalid> wrote:
>>> > > >
>>> > > > Now that Scala 3 support has been merged with the release of
>>> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
>>> that
>>> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
>>> > > everything
>>> > > > is working as intended and a milestone release should signal to the
>>> > > > community to "please use it to test it".
>>> > > >
>>> > > > Since scala steward support is merged[2] doing the milestone when
>>> > > > the update PR's are created early next week seems like a good
>>> candidate
>>> > > > in terms of time. There also is a question of whether we should
>>> also
>>> > > > fix the issue with the latest oracle version[2] for the M1.
>>> > > >
>>> > > > Thoughts?
>>> > > >
>>> > > > 1:
>>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
>>> > > > 2:
>>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
>>> > > > 3:
>>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>>> > > >
>>> > > > --
>>> > > >
>>> > > > Matthew de Detrich
>>> > > >
>>> > > > *Aiven Deutschland GmbH*
>>> > > >
>>> > > > Immanuelkirchstraße 26, 10405 Berlin
>>> > > >
>>> > > > Alexanderufer 3-7, 10117 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
>>> >
>>> > Alexanderufer 3-7, 10117 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
>>
>> Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
With all of the PR's from Scala Steward merged, I would advocate for an M1
release tomorrow
unless there is a strong objection otherwise.
Not going to rehash in details the reasons why for an M1 rather than a full
release, but we have another
driver mssql which also may require breaking changes in the future[1] ontop
of oracle[2] and since
I would like to ideally make postgres-persistence-jdbc SemVer compatible it
makes sense to make
the M1 release now, also to be fair to people waiting for Slick 3.5.x
support.
Hopefully with an M1 release, more people will actually use
pekko-persistence-jdbc so that we can
get some contributions for the oracle/mssql drivers.
On Thu, Mar 7, 2024 at 4:27 PM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> > pekko-persistence-jdbc is not downloaded very often from Maven
> Central. I doubt whether us releasing a milestone release will help
> Slick testing much.
>
> Well that can also be because for a lot of users the current
> pekko-persistence-jdbc wasn't really usable outside of migrating
> from akka to pekko because it was stuck on a really old version of Slick
> (3.3.x).
>
> In other words if anything the current low download rate from Maven central
> can be indicating that in fact users were in fact waiting for an RC style
> of release
> to test/use Slick 3.5.x and there definitely was multiple people in the
> community asking
> for it (even in the PR itself[1]!)
>
> > Regarding Oracle testing, it would be good to work out what is going
> on with that strange region error. If we have any Oracle experts, it
> it would be great to get this sorted out.
>
> Agreed, and from the sounds of the PR it may break the API? If so, hence
> another reason for an M1 now in case this may happen.
>
> 1:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
>
> On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com> wrote:
>
>> pekko-persistence-jdbc is not downloaded very often from Maven
>> Central. I doubt whether us releasing a milestone release will help
>> Slick testing much.
>>
>> Regarding Oracle testing, it would be good to work out what is going
>> on with that strange region error. If we have any Oracle experts, it
>> would be great to get this sorted out.
>>
>> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
>> <ma...@aiven.io.invalid> wrote:
>> >
>> > > I would favour just making a full 1.1.0 release. I don't see the
>> > benefit of having a milestone release.
>> >
>> > It was requested for us to do an RC so the community could properly test
>> > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
>> > always be in a releasable state[1] and hence I suspect that no one
>> really
>> > tested
>> > pekko-persistence-jdbc because it wasn't really announced anywhere. The
>> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
>> it's
>> > warranted
>> > to be more prudent here.
>> >
>> > Also we need to make sure that the project works properly with
>> pekko-core
>> > 1.1.x
>> > along with all of the inlining and other changes and pekko-core 1.1.x
>> hasn't
>> > even been released yet.
>> >
>> > Support for the latest oracle[2] is also something that we may want to
>> add
>> > after M1,
>> > this seems to be undecided?
>> >
>> > 1:
>> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
>> > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>> >
>> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
>> >
>> > > I would favour just making a full 1.1.0 release. I don't see the
>> > > benefit of having a milestone release.
>> > >
>> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
>> > > <ma...@aiven.io.invalid> wrote:
>> > > >
>> > > > Now that Scala 3 support has been merged with the release of
>> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
>> that
>> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
>> > > everything
>> > > > is working as intended and a milestone release should signal to the
>> > > > community to "please use it to test it".
>> > > >
>> > > > Since scala steward support is merged[2] doing the milestone when
>> > > > the update PR's are created early next week seems like a good
>> candidate
>> > > > in terms of time. There also is a question of whether we should also
>> > > > fix the issue with the latest oracle version[2] for the M1.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > 1:
>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
>> > > > 2:
>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
>> > > > 3:
>> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>> > > >
>> > > > --
>> > > >
>> > > > Matthew de Detrich
>> > > >
>> > > > *Aiven Deutschland GmbH*
>> > > >
>> > > > Immanuelkirchstraße 26, 10405 Berlin
>> > > >
>> > > > Alexanderufer 3-7, 10117 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
>> >
>> > Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> pekko-persistence-jdbc is not downloaded very often from Maven
Central. I doubt whether us releasing a milestone release will help
Slick testing much.
Well that can also be because for a lot of users the current
pekko-persistence-jdbc wasn't really usable outside of migrating
from akka to pekko because it was stuck on a really old version of Slick
(3.3.x).
In other words if anything the current low download rate from Maven central
can be indicating that in fact users were in fact waiting for an RC style
of release
to test/use Slick 3.5.x and there definitely was multiple people in the
community asking
for it (even in the PR itself[1]!)
> Regarding Oracle testing, it would be good to work out what is going
on with that strange region error. If we have any Oracle experts, it
it would be great to get this sorted out.
Agreed, and from the sounds of the PR it may break the API? If so, hence
another reason for an M1 now in case this may happen.
1:
https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44#pullrequestreview-1521620887
On Thu, Mar 7, 2024 at 4:20 PM PJ Fanning <fa...@gmail.com> wrote:
> pekko-persistence-jdbc is not downloaded very often from Maven
> Central. I doubt whether us releasing a milestone release will help
> Slick testing much.
>
> Regarding Oracle testing, it would be good to work out what is going
> on with that strange region error. If we have any Oracle experts, it
> would be great to get this sorted out.
>
> On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > > I would favour just making a full 1.1.0 release. I don't see the
> > benefit of having a milestone release.
> >
> > It was requested for us to do an RC so the community could properly test
> > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> > always be in a releasable state[1] and hence I suspect that no one really
> > tested
> > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
> it's
> > warranted
> > to be more prudent here.
> >
> > Also we need to make sure that the project works properly with pekko-core
> > 1.1.x
> > along with all of the inlining and other changes and pekko-core 1.1.x
> hasn't
> > even been released yet.
> >
> > Support for the latest oracle[2] is also something that we may want to
> add
> > after M1,
> > this seems to be undecided?
> >
> > 1:
> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >
> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> >
> > > I would favour just making a full 1.1.0 release. I don't see the
> > > benefit of having a milestone release.
> > >
> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > > >
> > > > Now that Scala 3 support has been merged with the release of
> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
> that
> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > > everything
> > > > is working as intended and a milestone release should signal to the
> > > > community to "please use it to test it".
> > > >
> > > > Since scala steward support is merged[2] doing the milestone when
> > > > the update PR's are created early next week seems like a good
> candidate
> > > > in terms of time. There also is a question of whether we should also
> > > > fix the issue with the latest oracle version[2] for the M1.
> > > >
> > > > Thoughts?
> > > >
> > > > 1:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > > 2:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > > 3:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 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
> >
> > Alexanderufer 3-7, 10117 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
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by PJ Fanning <fa...@gmail.com>.
pekko-persistence-jdbc is not downloaded very often from Maven
Central. I doubt whether us releasing a milestone release will help
Slick testing much.
Regarding Oracle testing, it would be good to work out what is going
on with that strange region error. If we have any Oracle experts, it
would be great to get this sorted out.
On Thu, 7 Mar 2024 at 16:03, Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
>
> > I would favour just making a full 1.1.0 release. I don't see the
> benefit of having a milestone release.
>
> It was requested for us to do an RC so the community could properly test
> Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> always be in a releasable state[1] and hence I suspect that no one really
> tested
> pekko-persistence-jdbc because it wasn't really announced anywhere. The
> changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think it's
> warranted
> to be more prudent here.
>
> Also we need to make sure that the project works properly with pekko-core
> 1.1.x
> along with all of the inlining and other changes and pekko-core 1.1.x hasn't
> even been released yet.
>
> Support for the latest oracle[2] is also something that we may want to add
> after M1,
> this seems to be undecided?
>
> 1: https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>
> On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
>
> > I would favour just making a full 1.1.0 release. I don't see the
> > benefit of having a milestone release.
> >
> > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > <ma...@aiven.io.invalid> wrote:
> > >
> > > Now that Scala 3 support has been merged with the release of
> > > Slick 3.5.0[1] I think it's a good time to make a M1 release given that
> > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > everything
> > > is working as intended and a milestone release should signal to the
> > > community to "please use it to test it".
> > >
> > > Since scala steward support is merged[2] doing the milestone when
> > > the update PR's are created early next week seems like a good candidate
> > > in terms of time. There also is a question of whether we should also
> > > fix the issue with the latest oracle version[2] for the M1.
> > >
> > > Thoughts?
> > >
> > > 1: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > 3: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by PJ Fanning <fa...@apache.org>.
I added a comment to the wrong thread:
https://lists.apache.org/thread/qdbbm36bxx6vhj67tjx4s2ym2bg97zhf
I think we have all the PRs for this release ready. One is approved and hopefully will be merged soon.
If someone wants to release manage this release then get in touch. Otherwise, I'll look after it and aim to start maybe tomorrow evening.
On 2024/04/02 13:24:49 PJ Fanning wrote:
> This release is blocked by this:
>
> https://github.com/apache/pekko/discussions/1233
>
> We may not be adding additional API methods but it seems likely that we will change the way that the deletion of durable state objects works.
>
>
> On 2024/03/26 08:59:16 Matthew de Detrich wrote:
> > > This does not care about source compatibility, and allows behavioural
> > and dependency changes to a large extent (as long as X doesn't rely on
> > specific behaviour of Y or its dependencies). While we use MiMa to check
> > we don't accidentally introduce binary incompatibilities, not every change
> > that gets flagged by MiMa is in fact problematic: indeed, modules marked
> > ApiMayChange or InternalApi are fine to change, as they shouldn't be
> > relied on by other libraries.
> >
> > This I am aware but specifically in the case of Slick, iirc the
> > changes that MiMa
> > complained about from Slick 3.3.x to 3.3.5 were of concern and not false
> > alarms and it wasn't just in the ApiMayChange/InternalApi, i.e.
> > https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes#L25-L34
> > is a public class
> >
> > > Do we have any obligation to maintain old branches? I'm not sure we should.
> >
> > This is something we still need to discuss, its just to be aware of. It becomes
> > increasingly concerning if underlying critical libraries constantly
> > break ABI and users
> > of those libraries can't always update to the latest version of that
> > underlying library
> > (which is understandable). The most extreme example of this is pekko-connectors,
> > if we applied semver there we would have something ridiculous like 10
> > major version
> > bumps in a year which is why we are exploring splitting out the
> > various connectors in
> > their own modules since some rarely update in a breaking way and some update
> > frequently in a breaking way.
> >
> > > I'd say the core question is: could I use Pekko Projection 1.0.0 with the
> > to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
> > as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
> > consider releasing it as 2.0.0-M1 (or 2.0.0, no strong preference).
> >
> > Given what I said about MiMa earlier, if I am correct then the answer is no
> > in which case it should be 2.0.0-M1/2.0.0 and I should add back in the
> > sbt SemVer versionScheme.
> >
> > Others wdyt?
> >
> > On Tue, Mar 26, 2024 at 9:48 AM Arnout Engelen <en...@apache.org> wrote:
> > >
> > > On Tue, Mar 26, 2024 at 9:16 AM Matthew de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > >
> > > > > If I understand correctly we want to create this M1 because we don't feel
> > > > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > > > to try an M1 than they are to try the snapshots from
> > > >
> > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > > > ? Should they be?
> > > >
> > > > In my opinion, most definitely yes. Almost no one uses snapshots
> > > > unless they are eager to try
> > > > a new feature that they are personally waiting for.
> > >
> > >
> > > Right - wouldn't Slick 3.5 support be such a feature?
> > >
> > >
> > > > Is this ideal? No. I think that largely this is probably a result of
> > > > ASF process being foreign to
> > > > a lot of Scala users/OS projects so its something that should get
> > > > better over time but aside from
> > > > that there are legitimate concerns that the changes in Slick 3.5.x are
> > > > so big that an -M1 is
> > > > warranted. As stated before when Slick 3.5.0-RC1 came out, because we
> > > > have a policy
> > > > of always needing the current state of release branches + main to be
> > > > in a releasable state we
> > > > couldn't deliver a snapshot/milestone/RC etc etc of our own that users
> > > > could test to make sure
> > > > that Slick 3.5.x could work
> > > >
> > >
> > > We could (and did) as soon as Slick 3.5.0 came out, though, right?
> > >
> > > > This release contains a number of binary-incompatible changes that were
> > > > excluded from MiMa[1]. In the future, it would be really helpful to
> > > > document in the exclusion file why these exclusions are warranted. I
> > > > understand from [2] that these changes don't "really affect the user facing
> > > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > > > It'd be good to more consistently mark things 'ApiMayChange' (or
> > > > 'InternalApi') in the future.
> > > >
> > > > So I actually want to remove SemVer from this module precisely because
> > > > we are expecting
> > > > to break it so many times. Then again, we can just leave in SemVer and
> > > > bump the major,
> > > > I am not that picky about this but I guess looking forward the main
> > > > reason to not subscribe
> > > > to SemVer for the jdbc module specifically is to not have to deal with
> > > > large number of
> > > > major version bumps which can be a risk given Slick's history of
> > > > breakages (same deal
> > > > with gRPC).
> > > >
> > > > Still, in [3] we do call this a 'breaking update' that will impact
> > > > pekko-projection. What does this breakage look like? By what criterium
> > > > (existing or to be formulated) is this breakage in a category that is
> > > > exempt from requiring a major version bump?
> > > >
> > > > So yes it is a breaking update, both in terms of MiMA and in source
> > > > code as well. This is
> > > > due to the Slick 3.3.x to 3.5.x update. If we think its more
> > > > appropriate to stick to SemVer and
> > > > just bump the major I am happy with that, we just open ourselves to
> > > > risk of having lots of major
> > > > version bumps in the future
> > >
> > >
> > > Regardless of whether we do SemVer, I think we should be somewhat
> > > explicit about what kinds of changes should happen in a major version
> > > bump.
> > >
> > > Personally I find SemVer overly strict in that I'm fine with adding features
> > > in a backwards-compatible way in a patch version, but I don't feel too
> > > strongly about this.
> > >
> > > I do think the binary compatibility rules[0] are still sensible. The
> > > intuition
> > > behind those rules is: if you're depending on library X which depends on
> > > pekko module version Y, you should generally be able to upgrade Y within
> > > minor versions without also upgrading X. This is extremely helpful as it
> > > means updates of Y don't force a release of X, which saves a lot of work
> > > releasing.
> > >
> > > This does not care about source compatibility, and allows behavioural
> > > and dependency changes to a large extent (as long as X doesn't rely on
> > > specific behaviour of Y or its dependencies). While we use MiMa to check
> > > we don't accidentally introduce binary incompatibilities, not every change
> > > that gets flagged by MiMa is in fact problematic: indeed, modules marked
> > > ApiMayChange or InternalApi are fine to change, as they shouldn't be
> > > relied on by other libraries.
> > >
> > > I'd say the core question is: could I use Pekko Projection 1.0.0 with the
> > > to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
> > > as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
> > > consider releasing as 2.0.0-M1 (or 2.0.0, no strong preference).
> > >
> > > [0]:
> > > https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html
> > >
> > >
> > > > which may mean maintaining a lot of
> > > > branches which does add overhead.
> > > >
> > >
> > > Do we have any obligation to maintain old branches? I'm not sure we should.
> > >
> > >
> > > Kind regards,
> > >
> > > Arnout
> > >
> > >
> > > > On Mon, Mar 25, 2024 at 4:46 PM Arnout Engelen <en...@apache.org> wrote:
> > > > >
> > > > > 1) 1.1.0 or 1.1.0-M1?
> > > > >
> > > > > I, too, am somewhat wary of the confusion introduced by creating
> > > > > 'milestone' releases for various reasons.
> > > > >
> > > > > If I understand correctly we want to create this M1 because we don't feel
> > > > > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > > > > to try an M1 than they are to try the snapshots from
> > > > >
> > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > > > > ? Should they be?
> > > > >
> > > > > I can sort of see this being a 'chicken and egg' problem and am not
> > > > opposed
> > > > > to releasing it as M1. In the future I hope we can get enough testing
> > > > > through the snapshots and not need such 'milestone' releases anymore,
> > > > > though.
> > > > >
> > > > > 2) 1.1.0-M1 or 2.0.0-M1?
> > > > >
> > > > > This release contains a number of binary-incompatible changes that were
> > > > > excluded from MiMa[1]. In the future, it would be really helpful to
> > > > > document in the exclusion file why these exclusions are warranted. I
> > > > > understand from [2] that these changes don't "really affect the user
> > > > facing
> > > > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > > > > It'd be good to more consistently mark things 'ApiMayChange' (or
> > > > > 'InternalApi') in the future.
> > > > >
> > > > > Still, in [3] we do call this a 'breaking update' that will impact
> > > > > pekko-projection. What does this breakage look like? By what criterium
> > > > > (existing or to be formulated) is this breakage in a category that is
> > > > > exempt from requiring a major version bump?
> > > > >
> > > > > [1]:
> > > > >
> > > > https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes
> > > > > [2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3
> > > > > [3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7
> > > > >
> > > > > On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich
> > > > > <ma...@aiven.io.invalid> wrote:
> > > > >
> > > > > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > > > benefit of having a milestone release.
> > > > > >
> > > > > > It was requested for us to do an RC so the community could properly
> > > > test
> > > > > > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> > > > > > always be in a releasable state[1] and hence I suspect that no one
> > > > really
> > > > > > tested
> > > > > > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> > > > > > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
> > > > it's
> > > > > > warranted
> > > > > > to be more prudent here.
> > > > > >
> > > > > > Also we need to make sure that the project works properly with
> > > > pekko-core
> > > > > > 1.1.x
> > > > > > along with all of the inlining and other changes and pekko-core 1.1.x
> > > > > > hasn't
> > > > > > even been released yet.
> > > > > >
> > > > > > Support for the latest oracle[2] is also something that we may want to
> > > > add
> > > > > > after M1,
> > > > > > this seems to be undecided?
> > > > > >
> > > > > > 1:
> > > > > >
> > > > https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > > > > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > > > >
> > > > > > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> > > > > >
> > > > > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > > > > benefit of having a milestone release.
> > > > > > >
> > > > > > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > > > > > > <ma...@aiven.io.invalid> wrote:
> > > > > > > >
> > > > > > > > Now that Scala 3 support has been merged with the release of
> > > > > > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
> > > > that
> > > > > > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > > > > > > everything
> > > > > > > > is working as intended and a milestone release should signal to the
> > > > > > > > community to "please use it to test it".
> > > > > > > >
> > > > > > > > Since scala steward support is merged[2] doing the milestone when
> > > > > > > > the update PR's are created early next week seems like a good
> > > > candidate
> > > > > > > > in terms of time. There also is a question of whether we should
> > > > also
> > > > > > > > fix the issue with the latest oracle version[2] for the M1.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > > > 1:
> > > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > > > > > > 2:
> > > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > > > > > > 3:
> > > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Matthew de Detrich
> > > > > > > >
> > > > > > > > *Aiven Deutschland GmbH*
> > > > > > > >
> > > > > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > > > > >
> > > > > > > > Alexanderufer 3-7, 10117 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
> > > > > >
> > > > > > Alexanderufer 3-7, 10117 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
> > > > > Apache Pekko PMC member, ASF Member
> > > > > NixOS Committer
> > > > > Independent Open Source consultant
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > Aiven Deutschland GmbH
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 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
> > > >
> > > >
> > >
> > > --
> > > Arnout Engelen
> > > ASF Security Response
> > > Apache Pekko PMC member, ASF Member
> > > NixOS Committer
> > > Independent Open Source consultant
> >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > Aiven Deutschland GmbH
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 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
> >
> >
>
> ---------------------------------------------------------------------
> 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by PJ Fanning <fa...@apache.org>.
This release is blocked by this:
https://github.com/apache/pekko/discussions/1233
We may not be adding additional API methods but it seems likely that we will change the way that the deletion of durable state objects works.
On 2024/03/26 08:59:16 Matthew de Detrich wrote:
> > This does not care about source compatibility, and allows behavioural
> and dependency changes to a large extent (as long as X doesn't rely on
> specific behaviour of Y or its dependencies). While we use MiMa to check
> we don't accidentally introduce binary incompatibilities, not every change
> that gets flagged by MiMa is in fact problematic: indeed, modules marked
> ApiMayChange or InternalApi are fine to change, as they shouldn't be
> relied on by other libraries.
>
> This I am aware but specifically in the case of Slick, iirc the
> changes that MiMa
> complained about from Slick 3.3.x to 3.3.5 were of concern and not false
> alarms and it wasn't just in the ApiMayChange/InternalApi, i.e.
> https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes#L25-L34
> is a public class
>
> > Do we have any obligation to maintain old branches? I'm not sure we should.
>
> This is something we still need to discuss, its just to be aware of. It becomes
> increasingly concerning if underlying critical libraries constantly
> break ABI and users
> of those libraries can't always update to the latest version of that
> underlying library
> (which is understandable). The most extreme example of this is pekko-connectors,
> if we applied semver there we would have something ridiculous like 10
> major version
> bumps in a year which is why we are exploring splitting out the
> various connectors in
> their own modules since some rarely update in a breaking way and some update
> frequently in a breaking way.
>
> > I'd say the core question is: could I use Pekko Projection 1.0.0 with the
> to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
> as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
> consider releasing it as 2.0.0-M1 (or 2.0.0, no strong preference).
>
> Given what I said about MiMa earlier, if I am correct then the answer is no
> in which case it should be 2.0.0-M1/2.0.0 and I should add back in the
> sbt SemVer versionScheme.
>
> Others wdyt?
>
> On Tue, Mar 26, 2024 at 9:48 AM Arnout Engelen <en...@apache.org> wrote:
> >
> > On Tue, Mar 26, 2024 at 9:16 AM Matthew de Detrich
> > <ma...@aiven.io.invalid> wrote:
> >
> > > > If I understand correctly we want to create this M1 because we don't feel
> > > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > > to try an M1 than they are to try the snapshots from
> > >
> > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > > ? Should they be?
> > >
> > > In my opinion, most definitely yes. Almost no one uses snapshots
> > > unless they are eager to try
> > > a new feature that they are personally waiting for.
> >
> >
> > Right - wouldn't Slick 3.5 support be such a feature?
> >
> >
> > > Is this ideal? No. I think that largely this is probably a result of
> > > ASF process being foreign to
> > > a lot of Scala users/OS projects so its something that should get
> > > better over time but aside from
> > > that there are legitimate concerns that the changes in Slick 3.5.x are
> > > so big that an -M1 is
> > > warranted. As stated before when Slick 3.5.0-RC1 came out, because we
> > > have a policy
> > > of always needing the current state of release branches + main to be
> > > in a releasable state we
> > > couldn't deliver a snapshot/milestone/RC etc etc of our own that users
> > > could test to make sure
> > > that Slick 3.5.x could work
> > >
> >
> > We could (and did) as soon as Slick 3.5.0 came out, though, right?
> >
> > > This release contains a number of binary-incompatible changes that were
> > > excluded from MiMa[1]. In the future, it would be really helpful to
> > > document in the exclusion file why these exclusions are warranted. I
> > > understand from [2] that these changes don't "really affect the user facing
> > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > > It'd be good to more consistently mark things 'ApiMayChange' (or
> > > 'InternalApi') in the future.
> > >
> > > So I actually want to remove SemVer from this module precisely because
> > > we are expecting
> > > to break it so many times. Then again, we can just leave in SemVer and
> > > bump the major,
> > > I am not that picky about this but I guess looking forward the main
> > > reason to not subscribe
> > > to SemVer for the jdbc module specifically is to not have to deal with
> > > large number of
> > > major version bumps which can be a risk given Slick's history of
> > > breakages (same deal
> > > with gRPC).
> > >
> > > Still, in [3] we do call this a 'breaking update' that will impact
> > > pekko-projection. What does this breakage look like? By what criterium
> > > (existing or to be formulated) is this breakage in a category that is
> > > exempt from requiring a major version bump?
> > >
> > > So yes it is a breaking update, both in terms of MiMA and in source
> > > code as well. This is
> > > due to the Slick 3.3.x to 3.5.x update. If we think its more
> > > appropriate to stick to SemVer and
> > > just bump the major I am happy with that, we just open ourselves to
> > > risk of having lots of major
> > > version bumps in the future
> >
> >
> > Regardless of whether we do SemVer, I think we should be somewhat
> > explicit about what kinds of changes should happen in a major version
> > bump.
> >
> > Personally I find SemVer overly strict in that I'm fine with adding features
> > in a backwards-compatible way in a patch version, but I don't feel too
> > strongly about this.
> >
> > I do think the binary compatibility rules[0] are still sensible. The
> > intuition
> > behind those rules is: if you're depending on library X which depends on
> > pekko module version Y, you should generally be able to upgrade Y within
> > minor versions without also upgrading X. This is extremely helpful as it
> > means updates of Y don't force a release of X, which saves a lot of work
> > releasing.
> >
> > This does not care about source compatibility, and allows behavioural
> > and dependency changes to a large extent (as long as X doesn't rely on
> > specific behaviour of Y or its dependencies). While we use MiMa to check
> > we don't accidentally introduce binary incompatibilities, not every change
> > that gets flagged by MiMa is in fact problematic: indeed, modules marked
> > ApiMayChange or InternalApi are fine to change, as they shouldn't be
> > relied on by other libraries.
> >
> > I'd say the core question is: could I use Pekko Projection 1.0.0 with the
> > to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
> > as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
> > consider releasing as 2.0.0-M1 (or 2.0.0, no strong preference).
> >
> > [0]:
> > https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html
> >
> >
> > > which may mean maintaining a lot of
> > > branches which does add overhead.
> > >
> >
> > Do we have any obligation to maintain old branches? I'm not sure we should.
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> >
> > > On Mon, Mar 25, 2024 at 4:46 PM Arnout Engelen <en...@apache.org> wrote:
> > > >
> > > > 1) 1.1.0 or 1.1.0-M1?
> > > >
> > > > I, too, am somewhat wary of the confusion introduced by creating
> > > > 'milestone' releases for various reasons.
> > > >
> > > > If I understand correctly we want to create this M1 because we don't feel
> > > > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > > > to try an M1 than they are to try the snapshots from
> > > >
> > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > > > ? Should they be?
> > > >
> > > > I can sort of see this being a 'chicken and egg' problem and am not
> > > opposed
> > > > to releasing it as M1. In the future I hope we can get enough testing
> > > > through the snapshots and not need such 'milestone' releases anymore,
> > > > though.
> > > >
> > > > 2) 1.1.0-M1 or 2.0.0-M1?
> > > >
> > > > This release contains a number of binary-incompatible changes that were
> > > > excluded from MiMa[1]. In the future, it would be really helpful to
> > > > document in the exclusion file why these exclusions are warranted. I
> > > > understand from [2] that these changes don't "really affect the user
> > > facing
> > > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > > > It'd be good to more consistently mark things 'ApiMayChange' (or
> > > > 'InternalApi') in the future.
> > > >
> > > > Still, in [3] we do call this a 'breaking update' that will impact
> > > > pekko-projection. What does this breakage look like? By what criterium
> > > > (existing or to be formulated) is this breakage in a category that is
> > > > exempt from requiring a major version bump?
> > > >
> > > > [1]:
> > > >
> > > https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes
> > > > [2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3
> > > > [3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7
> > > >
> > > > On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich
> > > > <ma...@aiven.io.invalid> wrote:
> > > >
> > > > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > > benefit of having a milestone release.
> > > > >
> > > > > It was requested for us to do an RC so the community could properly
> > > test
> > > > > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> > > > > always be in a releasable state[1] and hence I suspect that no one
> > > really
> > > > > tested
> > > > > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> > > > > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
> > > it's
> > > > > warranted
> > > > > to be more prudent here.
> > > > >
> > > > > Also we need to make sure that the project works properly with
> > > pekko-core
> > > > > 1.1.x
> > > > > along with all of the inlining and other changes and pekko-core 1.1.x
> > > > > hasn't
> > > > > even been released yet.
> > > > >
> > > > > Support for the latest oracle[2] is also something that we may want to
> > > add
> > > > > after M1,
> > > > > this seems to be undecided?
> > > > >
> > > > > 1:
> > > > >
> > > https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > > > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > > >
> > > > > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> > > > >
> > > > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > > > benefit of having a milestone release.
> > > > > >
> > > > > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > > > > > <ma...@aiven.io.invalid> wrote:
> > > > > > >
> > > > > > > Now that Scala 3 support has been merged with the release of
> > > > > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
> > > that
> > > > > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > > > > > everything
> > > > > > > is working as intended and a milestone release should signal to the
> > > > > > > community to "please use it to test it".
> > > > > > >
> > > > > > > Since scala steward support is merged[2] doing the milestone when
> > > > > > > the update PR's are created early next week seems like a good
> > > candidate
> > > > > > > in terms of time. There also is a question of whether we should
> > > also
> > > > > > > fix the issue with the latest oracle version[2] for the M1.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > 1:
> > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > > > > > 2:
> > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > > > > > 3:
> > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Matthew de Detrich
> > > > > > >
> > > > > > > *Aiven Deutschland GmbH*
> > > > > > >
> > > > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > > > >
> > > > > > > Alexanderufer 3-7, 10117 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
> > > > >
> > > > > Alexanderufer 3-7, 10117 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
> > > > Apache Pekko PMC member, ASF Member
> > > > NixOS Committer
> > > > Independent Open Source consultant
> > >
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > Aiven Deutschland GmbH
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 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
> > >
> > >
> >
> > --
> > Arnout Engelen
> > ASF Security Response
> > Apache Pekko PMC member, ASF Member
> > NixOS Committer
> > Independent Open Source consultant
>
>
>
> --
>
> Matthew de Detrich
>
> Aiven Deutschland GmbH
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> This does not care about source compatibility, and allows behavioural
and dependency changes to a large extent (as long as X doesn't rely on
specific behaviour of Y or its dependencies). While we use MiMa to check
we don't accidentally introduce binary incompatibilities, not every change
that gets flagged by MiMa is in fact problematic: indeed, modules marked
ApiMayChange or InternalApi are fine to change, as they shouldn't be
relied on by other libraries.
This I am aware but specifically in the case of Slick, iirc the
changes that MiMa
complained about from Slick 3.3.x to 3.3.5 were of concern and not false
alarms and it wasn't just in the ApiMayChange/InternalApi, i.e.
https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes#L25-L34
is a public class
> Do we have any obligation to maintain old branches? I'm not sure we should.
This is something we still need to discuss, its just to be aware of. It becomes
increasingly concerning if underlying critical libraries constantly
break ABI and users
of those libraries can't always update to the latest version of that
underlying library
(which is understandable). The most extreme example of this is pekko-connectors,
if we applied semver there we would have something ridiculous like 10
major version
bumps in a year which is why we are exploring splitting out the
various connectors in
their own modules since some rarely update in a breaking way and some update
frequently in a breaking way.
> I'd say the core question is: could I use Pekko Projection 1.0.0 with the
to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
consider releasing it as 2.0.0-M1 (or 2.0.0, no strong preference).
Given what I said about MiMa earlier, if I am correct then the answer is no
in which case it should be 2.0.0-M1/2.0.0 and I should add back in the
sbt SemVer versionScheme.
Others wdyt?
On Tue, Mar 26, 2024 at 9:48 AM Arnout Engelen <en...@apache.org> wrote:
>
> On Tue, Mar 26, 2024 at 9:16 AM Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > > If I understand correctly we want to create this M1 because we don't feel
> > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > to try an M1 than they are to try the snapshots from
> >
> > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > ? Should they be?
> >
> > In my opinion, most definitely yes. Almost no one uses snapshots
> > unless they are eager to try
> > a new feature that they are personally waiting for.
>
>
> Right - wouldn't Slick 3.5 support be such a feature?
>
>
> > Is this ideal? No. I think that largely this is probably a result of
> > ASF process being foreign to
> > a lot of Scala users/OS projects so its something that should get
> > better over time but aside from
> > that there are legitimate concerns that the changes in Slick 3.5.x are
> > so big that an -M1 is
> > warranted. As stated before when Slick 3.5.0-RC1 came out, because we
> > have a policy
> > of always needing the current state of release branches + main to be
> > in a releasable state we
> > couldn't deliver a snapshot/milestone/RC etc etc of our own that users
> > could test to make sure
> > that Slick 3.5.x could work
> >
>
> We could (and did) as soon as Slick 3.5.0 came out, though, right?
>
> > This release contains a number of binary-incompatible changes that were
> > excluded from MiMa[1]. In the future, it would be really helpful to
> > document in the exclusion file why these exclusions are warranted. I
> > understand from [2] that these changes don't "really affect the user facing
> > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > It'd be good to more consistently mark things 'ApiMayChange' (or
> > 'InternalApi') in the future.
> >
> > So I actually want to remove SemVer from this module precisely because
> > we are expecting
> > to break it so many times. Then again, we can just leave in SemVer and
> > bump the major,
> > I am not that picky about this but I guess looking forward the main
> > reason to not subscribe
> > to SemVer for the jdbc module specifically is to not have to deal with
> > large number of
> > major version bumps which can be a risk given Slick's history of
> > breakages (same deal
> > with gRPC).
> >
> > Still, in [3] we do call this a 'breaking update' that will impact
> > pekko-projection. What does this breakage look like? By what criterium
> > (existing or to be formulated) is this breakage in a category that is
> > exempt from requiring a major version bump?
> >
> > So yes it is a breaking update, both in terms of MiMA and in source
> > code as well. This is
> > due to the Slick 3.3.x to 3.5.x update. If we think its more
> > appropriate to stick to SemVer and
> > just bump the major I am happy with that, we just open ourselves to
> > risk of having lots of major
> > version bumps in the future
>
>
> Regardless of whether we do SemVer, I think we should be somewhat
> explicit about what kinds of changes should happen in a major version
> bump.
>
> Personally I find SemVer overly strict in that I'm fine with adding features
> in a backwards-compatible way in a patch version, but I don't feel too
> strongly about this.
>
> I do think the binary compatibility rules[0] are still sensible. The
> intuition
> behind those rules is: if you're depending on library X which depends on
> pekko module version Y, you should generally be able to upgrade Y within
> minor versions without also upgrading X. This is extremely helpful as it
> means updates of Y don't force a release of X, which saves a lot of work
> releasing.
>
> This does not care about source compatibility, and allows behavioural
> and dependency changes to a large extent (as long as X doesn't rely on
> specific behaviour of Y or its dependencies). While we use MiMa to check
> we don't accidentally introduce binary incompatibilities, not every change
> that gets flagged by MiMa is in fact problematic: indeed, modules marked
> ApiMayChange or InternalApi are fine to change, as they shouldn't be
> relied on by other libraries.
>
> I'd say the core question is: could I use Pekko Projection 1.0.0 with the
> to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
> as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
> consider releasing as 2.0.0-M1 (or 2.0.0, no strong preference).
>
> [0]:
> https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html
>
>
> > which may mean maintaining a lot of
> > branches which does add overhead.
> >
>
> Do we have any obligation to maintain old branches? I'm not sure we should.
>
>
> Kind regards,
>
> Arnout
>
>
> > On Mon, Mar 25, 2024 at 4:46 PM Arnout Engelen <en...@apache.org> wrote:
> > >
> > > 1) 1.1.0 or 1.1.0-M1?
> > >
> > > I, too, am somewhat wary of the confusion introduced by creating
> > > 'milestone' releases for various reasons.
> > >
> > > If I understand correctly we want to create this M1 because we don't feel
> > > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > > to try an M1 than they are to try the snapshots from
> > >
> > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > > ? Should they be?
> > >
> > > I can sort of see this being a 'chicken and egg' problem and am not
> > opposed
> > > to releasing it as M1. In the future I hope we can get enough testing
> > > through the snapshots and not need such 'milestone' releases anymore,
> > > though.
> > >
> > > 2) 1.1.0-M1 or 2.0.0-M1?
> > >
> > > This release contains a number of binary-incompatible changes that were
> > > excluded from MiMa[1]. In the future, it would be really helpful to
> > > document in the exclusion file why these exclusions are warranted. I
> > > understand from [2] that these changes don't "really affect the user
> > facing
> > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > > It'd be good to more consistently mark things 'ApiMayChange' (or
> > > 'InternalApi') in the future.
> > >
> > > Still, in [3] we do call this a 'breaking update' that will impact
> > > pekko-projection. What does this breakage look like? By what criterium
> > > (existing or to be formulated) is this breakage in a category that is
> > > exempt from requiring a major version bump?
> > >
> > > [1]:
> > >
> > https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes
> > > [2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3
> > > [3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7
> > >
> > > On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > >
> > > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > benefit of having a milestone release.
> > > >
> > > > It was requested for us to do an RC so the community could properly
> > test
> > > > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> > > > always be in a releasable state[1] and hence I suspect that no one
> > really
> > > > tested
> > > > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> > > > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
> > it's
> > > > warranted
> > > > to be more prudent here.
> > > >
> > > > Also we need to make sure that the project works properly with
> > pekko-core
> > > > 1.1.x
> > > > along with all of the inlining and other changes and pekko-core 1.1.x
> > > > hasn't
> > > > even been released yet.
> > > >
> > > > Support for the latest oracle[2] is also something that we may want to
> > add
> > > > after M1,
> > > > this seems to be undecided?
> > > >
> > > > 1:
> > > >
> > https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > >
> > > > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> > > >
> > > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > > benefit of having a milestone release.
> > > > >
> > > > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > > > > <ma...@aiven.io.invalid> wrote:
> > > > > >
> > > > > > Now that Scala 3 support has been merged with the release of
> > > > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
> > that
> > > > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > > > > everything
> > > > > > is working as intended and a milestone release should signal to the
> > > > > > community to "please use it to test it".
> > > > > >
> > > > > > Since scala steward support is merged[2] doing the milestone when
> > > > > > the update PR's are created early next week seems like a good
> > candidate
> > > > > > in terms of time. There also is a question of whether we should
> > also
> > > > > > fix the issue with the latest oracle version[2] for the M1.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > 1:
> > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > > > > 2:
> > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > > > > 3:
> > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Matthew de Detrich
> > > > > >
> > > > > > *Aiven Deutschland GmbH*
> > > > > >
> > > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > > >
> > > > > > Alexanderufer 3-7, 10117 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
> > > >
> > > > Alexanderufer 3-7, 10117 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
> > > Apache Pekko PMC member, ASF Member
> > > NixOS Committer
> > > Independent Open Source consultant
> >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > Aiven Deutschland GmbH
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 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
> >
> >
>
> --
> Arnout Engelen
> ASF Security Response
> Apache Pekko PMC member, ASF Member
> NixOS Committer
> Independent Open Source consultant
--
Matthew de Detrich
Aiven Deutschland GmbH
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Arnout Engelen <en...@apache.org>.
On Tue, Mar 26, 2024 at 9:16 AM Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
> > If I understand correctly we want to create this M1 because we don't feel
> the code is well-tested enough to warrant a 1.1.0? Are people more likely
> to try an M1 than they are to try the snapshots from
>
> https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> ? Should they be?
>
> In my opinion, most definitely yes. Almost no one uses snapshots
> unless they are eager to try
> a new feature that they are personally waiting for.
Right - wouldn't Slick 3.5 support be such a feature?
> Is this ideal? No. I think that largely this is probably a result of
> ASF process being foreign to
> a lot of Scala users/OS projects so its something that should get
> better over time but aside from
> that there are legitimate concerns that the changes in Slick 3.5.x are
> so big that an -M1 is
> warranted. As stated before when Slick 3.5.0-RC1 came out, because we
> have a policy
> of always needing the current state of release branches + main to be
> in a releasable state we
> couldn't deliver a snapshot/milestone/RC etc etc of our own that users
> could test to make sure
> that Slick 3.5.x could work
>
We could (and did) as soon as Slick 3.5.0 came out, though, right?
> This release contains a number of binary-incompatible changes that were
> excluded from MiMa[1]. In the future, it would be really helpful to
> document in the exclusion file why these exclusions are warranted. I
> understand from [2] that these changes don't "really affect the user facing
> APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> It'd be good to more consistently mark things 'ApiMayChange' (or
> 'InternalApi') in the future.
>
> So I actually want to remove SemVer from this module precisely because
> we are expecting
> to break it so many times. Then again, we can just leave in SemVer and
> bump the major,
> I am not that picky about this but I guess looking forward the main
> reason to not subscribe
> to SemVer for the jdbc module specifically is to not have to deal with
> large number of
> major version bumps which can be a risk given Slick's history of
> breakages (same deal
> with gRPC).
>
> Still, in [3] we do call this a 'breaking update' that will impact
> pekko-projection. What does this breakage look like? By what criterium
> (existing or to be formulated) is this breakage in a category that is
> exempt from requiring a major version bump?
>
> So yes it is a breaking update, both in terms of MiMA and in source
> code as well. This is
> due to the Slick 3.3.x to 3.5.x update. If we think its more
> appropriate to stick to SemVer and
> just bump the major I am happy with that, we just open ourselves to
> risk of having lots of major
> version bumps in the future
Regardless of whether we do SemVer, I think we should be somewhat
explicit about what kinds of changes should happen in a major version
bump.
Personally I find SemVer overly strict in that I'm fine with adding features
in a backwards-compatible way in a patch version, but I don't feel too
strongly about this.
I do think the binary compatibility rules[0] are still sensible. The
intuition
behind those rules is: if you're depending on library X which depends on
pekko module version Y, you should generally be able to upgrade Y within
minor versions without also upgrading X. This is extremely helpful as it
means updates of Y don't force a release of X, which saves a lot of work
releasing.
This does not care about source compatibility, and allows behavioural
and dependency changes to a large extent (as long as X doesn't rely on
specific behaviour of Y or its dependencies). While we use MiMa to check
we don't accidentally introduce binary incompatibilities, not every change
that gets flagged by MiMa is in fact problematic: indeed, modules marked
ApiMayChange or InternalApi are fine to change, as they shouldn't be
relied on by other libraries.
I'd say the core question is: could I use Pekko Projection 1.0.0 with the
to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing
as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should
consider releasing as 2.0.0-M1 (or 2.0.0, no strong preference).
[0]:
https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html
> which may mean maintaining a lot of
> branches which does add overhead.
>
Do we have any obligation to maintain old branches? I'm not sure we should.
Kind regards,
Arnout
> On Mon, Mar 25, 2024 at 4:46 PM Arnout Engelen <en...@apache.org> wrote:
> >
> > 1) 1.1.0 or 1.1.0-M1?
> >
> > I, too, am somewhat wary of the confusion introduced by creating
> > 'milestone' releases for various reasons.
> >
> > If I understand correctly we want to create this M1 because we don't feel
> > the code is well-tested enough to warrant a 1.1.0? Are people more likely
> > to try an M1 than they are to try the snapshots from
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> > ? Should they be?
> >
> > I can sort of see this being a 'chicken and egg' problem and am not
> opposed
> > to releasing it as M1. In the future I hope we can get enough testing
> > through the snapshots and not need such 'milestone' releases anymore,
> > though.
> >
> > 2) 1.1.0-M1 or 2.0.0-M1?
> >
> > This release contains a number of binary-incompatible changes that were
> > excluded from MiMa[1]. In the future, it would be really helpful to
> > document in the exclusion file why these exclusions are warranted. I
> > understand from [2] that these changes don't "really affect the user
> facing
> > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> > It'd be good to more consistently mark things 'ApiMayChange' (or
> > 'InternalApi') in the future.
> >
> > Still, in [3] we do call this a 'breaking update' that will impact
> > pekko-projection. What does this breakage look like? By what criterium
> > (existing or to be formulated) is this breakage in a category that is
> > exempt from requiring a major version bump?
> >
> > [1]:
> >
> https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes
> > [2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3
> > [3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7
> >
> > On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich
> > <ma...@aiven.io.invalid> wrote:
> >
> > > > I would favour just making a full 1.1.0 release. I don't see the
> > > benefit of having a milestone release.
> > >
> > > It was requested for us to do an RC so the community could properly
> test
> > > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> > > always be in a releasable state[1] and hence I suspect that no one
> really
> > > tested
> > > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> > > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think
> it's
> > > warranted
> > > to be more prudent here.
> > >
> > > Also we need to make sure that the project works properly with
> pekko-core
> > > 1.1.x
> > > along with all of the inlining and other changes and pekko-core 1.1.x
> > > hasn't
> > > even been released yet.
> > >
> > > Support for the latest oracle[2] is also something that we may want to
> add
> > > after M1,
> > > this seems to be undecided?
> > >
> > > 1:
> > >
> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > >
> > > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> > >
> > > > I would favour just making a full 1.1.0 release. I don't see the
> > > > benefit of having a milestone release.
> > > >
> > > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > > > <ma...@aiven.io.invalid> wrote:
> > > > >
> > > > > Now that Scala 3 support has been merged with the release of
> > > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given
> that
> > > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > > > everything
> > > > > is working as intended and a milestone release should signal to the
> > > > > community to "please use it to test it".
> > > > >
> > > > > Since scala steward support is merged[2] doing the milestone when
> > > > > the update PR's are created early next week seems like a good
> candidate
> > > > > in terms of time. There also is a question of whether we should
> also
> > > > > fix the issue with the latest oracle version[2] for the M1.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > 1:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > > > 2:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > > > 3:
> https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > > >
> > > > > --
> > > > >
> > > > > Matthew de Detrich
> > > > >
> > > > > *Aiven Deutschland GmbH*
> > > > >
> > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > >
> > > > > Alexanderufer 3-7, 10117 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
> > >
> > > Alexanderufer 3-7, 10117 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
> > Apache Pekko PMC member, ASF Member
> > NixOS Committer
> > Independent Open Source consultant
>
>
>
> --
>
> Matthew de Detrich
>
> Aiven Deutschland GmbH
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 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
>
>
--
Arnout Engelen
ASF Security Response
Apache Pekko PMC member, ASF Member
NixOS Committer
Independent Open Source consultant
Re: [DISCUSS] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> If I understand correctly we want to create this M1 because we don't feel
the code is well-tested enough to warrant a 1.1.0? Are people more likely
to try an M1 than they are to try the snapshots from
https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
? Should they be?
In my opinion, most definitely yes. Almost no one uses snapshots
unless they are eager to try
a new feature that they are personally waiting for. Also from what I
have almost no one tests
out -RC's in staging either in the release process, only the release
managers/PMC does this.
Is this ideal? No. I think that largely this is probably a result of
ASF process being foreign to
a lot of Scala users/OS projects so its something that should get
better over time but aside from
that there are legitimate concerns that the changes in Slick 3.5.x are
so big that an -M1 is
warranted. As stated before when Slick 3.5.0-RC1 came out, because we
have a policy
of always needing the current state of release branches + main to be
in a releasable state we
couldn't deliver a snapshot/milestone/RC etc etc of our own that users
could test to make sure
that Slick 3.5.x could work
> This release contains a number of binary-incompatible changes that were
excluded from MiMa[1]. In the future, it would be really helpful to
document in the exclusion file why these exclusions are warranted. I
understand from [2] that these changes don't "really affect the user facing
APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
It'd be good to more consistently mark things 'ApiMayChange' (or
'InternalApi') in the future.
So I actually want to remove SemVer from this module precisely because
we are expecting
to break it so many times. Then again, we can just leave in SemVer and
bump the major,
I am not that picky about this but I guess looking forward the main
reason to not subscribe
to SemVer for the jdbc module specifically is to not have to deal with
large number of
major version bumps which can be a risk given Slick's history of
breakages (same deal
with gRPC).
> Still, in [3] we do call this a 'breaking update' that will impact
pekko-projection. What does this breakage look like? By what criterium
(existing or to be formulated) is this breakage in a category that is
exempt from requiring a major version bump?
So yes it is a breaking update, both in terms of MiMA and in source
code as well. This is
due to the Slick 3.3.x to 3.5.x update. If we think its more
appropriate to stick to SemVer and
just bump the major I am happy with that, we just open ourselves to
risk of having lots of major
version bumps in the future which may mean maintaining a lot of
branches which does add
overhead.
On Mon, Mar 25, 2024 at 4:46 PM Arnout Engelen <en...@apache.org> wrote:
>
> 1) 1.1.0 or 1.1.0-M1?
>
> I, too, am somewhat wary of the confusion introduced by creating
> 'milestone' releases for various reasons.
>
> If I understand correctly we want to create this M1 because we don't feel
> the code is well-tested enough to warrant a 1.1.0? Are people more likely
> to try an M1 than they are to try the snapshots from
> https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
> ? Should they be?
>
> I can sort of see this being a 'chicken and egg' problem and am not opposed
> to releasing it as M1. In the future I hope we can get enough testing
> through the snapshots and not need such 'milestone' releases anymore,
> though.
>
> 2) 1.1.0-M1 or 2.0.0-M1?
>
> This release contains a number of binary-incompatible changes that were
> excluded from MiMa[1]. In the future, it would be really helpful to
> document in the exclusion file why these exclusions are warranted. I
> understand from [2] that these changes don't "really affect the user facing
> APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
> It'd be good to more consistently mark things 'ApiMayChange' (or
> 'InternalApi') in the future.
>
> Still, in [3] we do call this a 'breaking update' that will impact
> pekko-projection. What does this breakage look like? By what criterium
> (existing or to be formulated) is this breakage in a category that is
> exempt from requiring a major version bump?
>
> [1]:
> https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes
> [2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3
> [3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7
>
> On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > > I would favour just making a full 1.1.0 release. I don't see the
> > benefit of having a milestone release.
> >
> > It was requested for us to do an RC so the community could properly test
> > Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> > always be in a releasable state[1] and hence I suspect that no one really
> > tested
> > pekko-persistence-jdbc because it wasn't really announced anywhere. The
> > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think it's
> > warranted
> > to be more prudent here.
> >
> > Also we need to make sure that the project works properly with pekko-core
> > 1.1.x
> > along with all of the inlining and other changes and pekko-core 1.1.x
> > hasn't
> > even been released yet.
> >
> > Support for the latest oracle[2] is also something that we may want to add
> > after M1,
> > this seems to be undecided?
> >
> > 1:
> > https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >
> > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> >
> > > I would favour just making a full 1.1.0 release. I don't see the
> > > benefit of having a milestone release.
> > >
> > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > > >
> > > > Now that Scala 3 support has been merged with the release of
> > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given that
> > > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > > everything
> > > > is working as intended and a milestone release should signal to the
> > > > community to "please use it to test it".
> > > >
> > > > Since scala steward support is merged[2] doing the milestone when
> > > > the update PR's are created early next week seems like a good candidate
> > > > in terms of time. There also is a question of whether we should also
> > > > fix the issue with the latest oracle version[2] for the M1.
> > > >
> > > > Thoughts?
> > > >
> > > > 1: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > > 3: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 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
> >
> > Alexanderufer 3-7, 10117 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
> Apache Pekko PMC member, ASF Member
> NixOS Committer
> Independent Open Source consultant
--
Matthew de Detrich
Aiven Deutschland GmbH
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Arnout Engelen <en...@apache.org>.
1) 1.1.0 or 1.1.0-M1?
I, too, am somewhat wary of the confusion introduced by creating
'milestone' releases for various reasons.
If I understand correctly we want to create this M1 because we don't feel
the code is well-tested enough to warrant a 1.1.0? Are people more likely
to try an M1 than they are to try the snapshots from
https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/
? Should they be?
I can sort of see this being a 'chicken and egg' problem and am not opposed
to releasing it as M1. In the future I hope we can get enough testing
through the snapshots and not need such 'milestone' releases anymore,
though.
2) 1.1.0-M1 or 2.0.0-M1?
This release contains a number of binary-incompatible changes that were
excluded from MiMa[1]. In the future, it would be really helpful to
document in the exclusion file why these exclusions are warranted. I
understand from [2] that these changes don't "really affect the user facing
APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'.
It'd be good to more consistently mark things 'ApiMayChange' (or
'InternalApi') in the future.
Still, in [3] we do call this a 'breaking update' that will impact
pekko-projection. What does this breakage look like? By what criterium
(existing or to be formulated) is this breakage in a category that is
exempt from requiring a major version bump?
[1]:
https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes
[2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3
[3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7
On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
> > I would favour just making a full 1.1.0 release. I don't see the
> benefit of having a milestone release.
>
> It was requested for us to do an RC so the community could properly test
> Slick 3.5.0-RC5 but we didn't do this because we want our projects to
> always be in a releasable state[1] and hence I suspect that no one really
> tested
> pekko-persistence-jdbc because it wasn't really announced anywhere. The
> changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think it's
> warranted
> to be more prudent here.
>
> Also we need to make sure that the project works properly with pekko-core
> 1.1.x
> along with all of the inlining and other changes and pekko-core 1.1.x
> hasn't
> even been released yet.
>
> Support for the latest oracle[2] is also something that we may want to add
> after M1,
> this seems to be undecided?
>
> 1:
> https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
> 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>
> On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
>
> > I would favour just making a full 1.1.0 release. I don't see the
> > benefit of having a milestone release.
> >
> > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> > <ma...@aiven.io.invalid> wrote:
> > >
> > > Now that Scala 3 support has been merged with the release of
> > > Slick 3.5.0[1] I think it's a good time to make a M1 release given that
> > > the changes in Slick 3.5.0 were so extensive, just to make sure
> > everything
> > > is working as intended and a milestone release should signal to the
> > > community to "please use it to test it".
> > >
> > > Since scala steward support is merged[2] doing the milestone when
> > > the update PR's are created early next week seems like a good candidate
> > > in terms of time. There also is a question of whether we should also
> > > fix the issue with the latest oracle version[2] for the M1.
> > >
> > > Thoughts?
> > >
> > > 1: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > > 3: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 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
>
> Alexanderufer 3-7, 10117 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
Apache Pekko PMC member, ASF Member
NixOS Committer
Independent Open Source consultant
Re: [DISCUSS] Pekko Persistence JDBC 1.1.0-M1 release
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> I would favour just making a full 1.1.0 release. I don't see the
benefit of having a milestone release.
It was requested for us to do an RC so the community could properly test
Slick 3.5.0-RC5 but we didn't do this because we want our projects to
always be in a releasable state[1] and hence I suspect that no one really
tested
pekko-persistence-jdbc because it wasn't really announced anywhere. The
changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think it's
warranted
to be more prudent here.
Also we need to make sure that the project works properly with pekko-core
1.1.x
along with all of the inlining and other changes and pekko-core 1.1.x hasn't
even been released yet.
Support for the latest oracle[2] is also something that we may want to add
after M1,
this seems to be undecided?
1: https://github.com/slick/slick/discussions/2891#discussioncomment-8550269
2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fa...@gmail.com> wrote:
> I would favour just making a full 1.1.0 release. I don't see the
> benefit of having a milestone release.
>
> On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > Now that Scala 3 support has been merged with the release of
> > Slick 3.5.0[1] I think it's a good time to make a M1 release given that
> > the changes in Slick 3.5.0 were so extensive, just to make sure
> everything
> > is working as intended and a milestone release should signal to the
> > community to "please use it to test it".
> >
> > Since scala steward support is merged[2] doing the milestone when
> > the update PR's are created early next week seems like a good candidate
> > in terms of time. There also is a question of whether we should also
> > fix the issue with the latest oracle version[2] for the M1.
> >
> > Thoughts?
> >
> > 1: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> > 3: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 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
Alexanderufer 3-7, 10117 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] Pekko Persistence JDBC 1.1.0-M1 release
Posted by PJ Fanning <fa...@gmail.com>.
I would favour just making a full 1.1.0 release. I don't see the
benefit of having a milestone release.
On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
>
> Now that Scala 3 support has been merged with the release of
> Slick 3.5.0[1] I think it's a good time to make a M1 release given that
> the changes in Slick 3.5.0 were so extensive, just to make sure everything
> is working as intended and a milestone release should signal to the
> community to "please use it to test it".
>
> Since scala steward support is merged[2] doing the milestone when
> the update PR's are created early next week seems like a good candidate
> in terms of time. There also is a question of whether we should also
> fix the issue with the latest oracle version[2] for the M1.
>
> Thoughts?
>
> 1: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44
> 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123
> 3: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 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