mdedetrich commented on PR #2555:
URL: https://github.com/apache/pekko/pull/2555#issuecomment-3649873338

   > The existing method causes us zero pain. 
   
   I'm sorry this is a terrible argument in general, I mean why did we go ahead 
and remove all of the Pekko 1.x deprecated methods in Pekko 2.x?
   
   I could just as easily argue that there was no reason for removing these 
those deprecated as it causes us zero pain and yet we did it.
   
   > Users might be using it.
   
   All evidence points to the contrary. We have been deprecating these methods 
for a while now and there hasn't been a single complaint.
   
   In fact I don't think it's ridiculous to claim that deprecating these Future 
methods and removing it in Pekko 2.x is causing us zero pain as well (that also 
includes our users)
   
   > We are in no position to tell anyone what long existing methods that they 
can and can't use.
   
   Yes we most certainly are if it's a breaking release of Pekko, that's the 
whole point of a breaking point release.
   
   > Users expect to be able to upgrade lib versions without any hassle. You 
can claim that a major release allows us to remove whatever you like but what 
you are really doing is convincing a large proportion of our users to not 
upgrade. These users choose to either:
   > 
   > * stick to an outdated release that doesn't get fixes
   > 
   > * or pay a company to provide them LTS on the old release
   > 
   > * or plan to move to a new set of libs that don't go around changing their 
APIs
   
   And again, we have been deprecating these methods for a while and no has 
complained and that's not surprising because it would be shocking if any Java 
users willingly used Scala Future.
   
   There is an obvious misalignment/tension here and rejecting PRs like this is 
in my view too far. Can we discuss this on the mailing list and make an 
executive decision on it. The whole premise of deprecating these Future methods 
in the java dsl is it should be done as soon as possible so we can actually get 
feedback from Java users on releases, and this PR should have been in Pekko 
1.4.0 for exactly this reason.
   
   I am on the verge of blocking future Pekko 1.x releases over this, as this 
argument comes up again and again and it's the same arguments that cause us to 
go around in circles.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to