Declare Java 8 support deprecated

[raboof]

If we declare Java 8 support deprecated in/before Pekko 1.1.0, we give ourselves the option to remove it in Pekko 1.2.0 (in the spirit of https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html#when-will-a-deprecated-method-be-removed-entirely).

Depending on feedback we might still decide to keep supporting Java 8 in 1.2.0, but I think deprecating it sends the right message, and it's good to have the option.

[He-Pin]

Maybe after 1.2.0 ? IIRC, @mdedetrich said they are using Java 8.

We can starting remove deprecated things in 1.2.0 and drop Java 8 （Scala 2.12) support in 1.3.0

[mdedetrich]

The original idea was to drop Java 8 support in 2.0.x, as it is both considered a breaking change and there are also some significant users of Pekko that rely on it.

We can bring it up again on the mailing list, but last time we did it we got pushback

[He-Pin]

I don't know much about others, but at my company, where only 13% application running with Java 11, so we have to publish our internal libraries with <release>8</release>.

[raboof]

The original idea was to drop Java 8 support in 2.0.x, as it is both considered a breaking change and there are also some significant users of Pekko that rely on it.

We can bring it up again on the mailing list, but last time we did it we got pushback

Could you link to this pushback on https://lists.apache.org/[email protected] or similar? I searched but couldn't find this thread.

[mdedetrich]

Could you link to this pushback on https://lists.apache.org/[email protected] or similar? I searched but couldn't find this thread.

https://lists.apache.org/thread/83xmcls29opo3o8q3mwdhdpqc6bvf69c

Note that at the time I pushed for 1.2.x but since then we ended up adopting/following semver so dropping it in Pekko 2.x.x seems more appropriate?

[raboof]

Could you link to this pushback on https://lists.apache.org/[email protected] or similar? I searched but couldn't find this thread.

https://lists.apache.org/thread/83xmcls29opo3o8q3mwdhdpqc6bvf69c

Thanks for the reference, that really helps.

Note that at the time I pushed for 1.2.x but since then we ended up adopting/following semver

small sidebar/rant: I notice that in Pekko it seems relatively common for people to make statements like "it was already decided that X", without linking to the place where that decision was made or documented. I like to think that I'm following Pekko relatively closely, but even for me that makes things hard/frustrating to follow - like now I'm digging through email archives again and none of https://lists.apache.org/[email protected], https://lists.apache.org/[email protected] or https://lists.apache.org/[email protected] seem to have particularly relevant hits for 'semver'. I think it would be really good, both for future maintenance and for attracting/retaining new/casual contributors, to make more of a habit of adding relevant links to such statements.

[mdedetrich]

small sidebar/rant: I notice that in Pekko it seems relatively common for people to make statements like "it was already decided that X", without linking to the place where that decision was made or documented. I like to think that I'm following Pekko relatively closely, but even for me that makes things hard/frustrating to follow - like now I'm digging through email archives again and none of https://lists.apache.org/[email protected], https://lists.apache.org/[email protected] or https://lists.apache.org/[email protected] seem to have particularly relevant hits for 'semver'. I think it would be really good, both for future maintenance and for attracting/retaining new/casual contributors, to make more of a habit of adding relevant links to such statements.

Agreed and apologies for being part of the habit. For me personally I am not that fond/used of mailing lists as a form of discussion as its very hard to search/organize/link (as is evidenced) and so I take the lazy way out (I would go as far as to argue that mailing lists are one of the most impractical ways to communite/organize software projects but thats my opinion). I personally have a preference for doing such discussions using github issues/discussions as you can do things like make a checklist/wiki of relevant discussions so we can easily refer to big decision topics (such as SemVer, dropping JDK8 etc etc)

The issue is that it then it becomes unclear as to whether a discussion should occur on a mailing list or not (as far as I can tell any non trivial decision should occur on mailing list as a vote but I may be wrong here). We can also explore creating a PIP (Pekko Improvement Proposal) process so design guidelines/goals are centralized in one spot with a clear sense of direction rather than discussions being made in various places

[raboof]

apologies for being part of the habit

No problem of course, not trying to point fingers :)

doing such discussions using github issues/discussions

Yeah, references to issues/PRs/discussions/wikis/etc are also useful - while those media have their advantages, none of them are particularly easy to find :)