update miglayout version#97
Conversation
update from miglayout version 3.7.4 to version 5.2. Required miglayout-core and miglayout-swing
|
@karlduderstadt Yes, I would love to update this. However, we need to test components of the SciJava ecosystem to ensure that MigLayout 5.2 does not break their behavior—and if it does, update the code accordingly to fix issues. There is an automated "melting pot" I can run to make sure that all components of e.g. Fiji still compile with passing tests. Do you think that is good enough? Or do you think it's possible that the new MigLayout might retain backwards API compatibility while breaking runtime behavior? Just to be safe, we should do a little manual testing of some MigLayout-driven GUIs as well. |
|
I don't have that much experience with miglayout, so I don't have a good feeling for what has changed between 3.7.3 and 5.2. I looked through the change logs and nothing jumped out at me. Seems to only be bug fixes and not major changes. But if there are problems, I wouldn't be surprised if the API is compatible but fields, buttons, checkboxes show up in strange places potentially making them unusable. So far I have seen nothing like that in my fiji with miglayout-core and miglayout-swing 5.2. I will do some more extensive testing. Are there any specific tools with more complex layouts that you think could have problems? Otherwise, it might take a while to test everything that uses miglayout. Should we remove the swing classifier? |
|
These components need upgrades:
I might have missed some more... |
|
A question for @ctrueden: do we need to bump the major version of all the updated components according to SemVer? Or is a minor version bump sufficient? |
Probably not. You'd only need to do that if the public API of that updated component changes. And it would only change if it e.g. has a method that return a MigLayout object that moved packages. Usually, underlying dependency changes—even major updates—entail only a patch level change. See also |
Each artifact's version should have a corresponding version property with the same name. And the swing classifier does not exist anymore.
|
Plunging ahead. If any downstream component is broken by this, we'll deal with it when it arises. |
|
@imagejan Thank you so much for filing all those PRs. All have been merged now, so the dependencies are sane. To eliminate the exclusions without repeatedly cutting pom-scijava releases, I'm considering simultaneously upgrading all the miglayout-dependent components preemptively as part of pom-scijava 29.0.0, and then doing patch releases from the bottom up. I'm proceeding with caution, and doing melting pot runs to avoid problems. |
|
@ctrueden @imagejan Thank you very much for pushing this forward!! I continued testing on my local Fiji and I didn't notice a problem, but it was unclear to me how to systematically test and report back. Let me know if I can still help in any way. At some point I removed the javafx miglayout as a dependency of our project, but it looks like I can add it back soon! Thanks! |
3 participants
Would it be possible to update to the more recent miglayout 5.2. This will require adding miglayout-core as an additional jar because now it is a dependency of miglayout-swing.
We are developing a javafx gui that uses the miglayout-javafx and this change will allow compatibility. Maybe miglayout-javafx should also be added, but I am not sure if other projects use it.
I have tested this update on my local Fiji and haven't see any issues. We are happy to perform any specific tests that might reveal issues.