You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The #367 issues made me think that over the time project dependencies can go stale without noticing, unless something is broken. Here I propose a process for maintainers to deal with.
Write a script that reads all the dependencies declared in various pom.xml files and also their declared version, if any.
The script cross checks with repositories to find the latest versions of each dependency as well as their minor or patch version under the same major version as declared (when possible).
The script lists this information in a tabular style (Markdown format) that can be pasted in a wiki page for tracking purpose (or in a file in the repo).
An extra column is added in the table manually to put a reason if a dependency can not be upgraded (with references to corresponding issues, if any).
Before releasing any version (specially pre-release versions), as part of the release checklist, run the script and check to see if changing dependencies to their latest version works as expected, if so then push those changes otherwise create tickets and add a note in the tracking table.
The text was updated successfully, but these errors were encountered:
Hi @ibnesayeed is this script something you are planning to write? It could be helpful to automatically detect out of date dependencies. Though, at this point, I would imagine most of the dependencies are highly out of date, which will require many changes to the code in order to upgrade. If someone wants to volunteer to work on dependency upgrades and the affiliated code changes (such a volunteer doesn't need to commit to upgrading ALL dependencies), please let us know--that would be great. :)
That would require me to learn how Java dependencies work, the tools and dependency parsers, as well as the working of Java repositories. Unfortunately, I have no intent, desire, or cycles to invest in that. However, I outlines a process here so that someone involved can look into it. Keeping dependencies up to date could be a pain, but in the long run it makes sure the software is secure and things don't go stale. This aggressive dependency update might also give more opportunities to write tests when things fail due to a dependency change.
The #367 issues made me think that over the time project dependencies can go stale without noticing, unless something is broken. Here I propose a process for maintainers to deal with.
pom.xml
files and also their declared version, if any.The text was updated successfully, but these errors were encountered: