-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support older mill 0.10.x 0.11.y patch versions #166
support older mill 0.10.x 0.11.y patch versions #166
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
@joan38 WDYT? Also, should this be updated to some mill 0.11.x version? https://github.com/joan38/mill-scalafix/blob/main/.mill-version |
@IdiosApps looks good. |
@IdiosApps Could you fix the compilation? Also could you explain the motivation for supporting older patch versions? |
I can try and fix it another day, sure. Like I said, I don't fully understand, but trying to copy the pattern I'm seeing 😅 @lefou could you explain it a bit? |
I understand mill is not forward compatible and therefore plugins need to be depending on older versions of mill than the end project is using. But why can't the end project upgrade the patch version? That is what I'm trying to understand. Also the example you linked seem to depend on 0.10.12 |
There are always reasons to not use the latest versions. (The OP just provided an example: using an older version because a newer minor version introduces an issue and nobody else saw it so far.) If it does not hurt, why should one want to limit the compatibility of a plugin to only the latest version? |
Btw, compatibility-wise, we're speaking about minor-versions here, as we are in early-semver which effectively means |
And regarding this PR, we can't lower the version back to |
I think Mill 0.10 is now a "legacy" version of Mill, and I would be okay supporting only its latest version ( |
Co-authored-by: Tobias Roeser <le.petit.fou@web.de>
This sounds reasonable. Yet, I'd like to ask why one should want to explicitly unsupport a certain version without any needs? We're talking about API here, not implementation. If the user runs with a newer version, e.g. to get all the upstream fixes and improvements, the plugin will use that newer version too. From a users perspective, there is no easy way to detect, whether a plugin was build against a compatible API, besides the binary platform version. When analyzing build issues, this kind of incompatibility is less obvious and may lead to obscure error messages. And, tbh, this is against any best practice in plugin development for any kind of system I ever worked with. |
I just want to bring to your awareness, that there is a I also found the following line in its
|
Mostly superseded by #172, which raised the lowest supported Mill version to 0.10.15. Maybe, the |
Good point ! |
Closing this one. Reopen if needed |
@lefou could you sanity check this is a good suggestion? 😅 I don't fully understand, but trying to copy the pattern I'm seeing. I've been looking for possible mill issues in the 0.11.1 -> 0.11.2 bump related to the
--disable-callgraph-validation
Mill issue.