mdedetrich commented on issue #2093: URL: https://github.com/apache/pekko/issues/2093#issuecomment-3261696021
> > if we want to do breaking changes in 2.0.x series (such as removing the methods that work with `Future` for Java users) the changes have to land in Pekko 1.x series because we have to then deprecate those methods. > > Can you remind me why that is? Afaik technically speaking with semver its not an issue either way, but as good custodians it makes sense that if we are going to break the API in 2.0.x, that those breakages should be marked as deprecated in 1.x series so that users are aware and the migration is easier, this is at least what @pjfanning wanted earlier if I understood correctly (see https://github.com/apache/pekko/issues/2093#issuecomment-3221993046). Its of course easier to just do all of the API changes in 2.0.x without caring about 1.x, but then it would be a big shock to users. > My preference is for changes like this to start on the main branch. When they are agreed and merged, we can then decide what if anything we would like to backport. This is actually how we normally operate even with small bug fixes. If we want the new API to be usable in 1.x and the migration to be easier (as said in https://github.com/apache/pekko/issues/2093#issuecomment-3221993046) I need to do the changes in 1.x series first because that would then act as a stepping stone to 2.x. Basically there needs to be a migration path in 1.x series for the current actor API to the new one so users can migrate in the 1.x series to the new API, and then in 2.0.0 we remove the old (ergo 1.x) actor API and just leave the `javadsl`/`scaladsl` one. I don't have an issue in working on main, its actually much easier but then we wouldn't have a nice migration path for users -- 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]
