Hi Arnout and all. Le lun. 10 févr. 2025 à 12:11, Arnout Engelen <enge...@apache.org> a écrit : > > On Mon, Feb 10, 2025 at 11:45 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Le lun. 10 févr. 2025 à 11:25, Arnout Engelen <enge...@apache.org> a > > écrit : > > > Do you mean we should leave out the whole line or just the "Thanks to > > > Dependabot" part? > > > > The whole line. > > > > > I tried to follow the convention from other Commons projects where each > > > dependency update gets such a line in the changelog. > > > > Well, the "convention" in math-related components was to follow the > > previous convention. ;-) Which was to do such dependency updates > > when deemed necessary (by a human), usually at the latest before a > > release. > > > > > I don't mind the lines > > > in the change log too much (it seems useful to see what got updated, > > > especially when we group update lines in the log). > > > > Information is useful; such updates "inter-releases" is not IMHO. > > > > As it stands, I prefer to not rely on Dependabot to do the change; the > > useful part of that tool is to make checks, and "say" that it would be > > harmless to update. > > > > Gotcha, I didn't realize different commons- components had different ways > of working here, sorry about that.
No need to; it's great that you'd care for all components. :-) > So for commons-math, you'd prefer Dependabot PRs to be created but not > merged (or at least not during regular development), right? Shall I > configure a '[not for merge]' prefix ( > https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs#adding-a-prefix-to-commit-messages) > for the generated commit/PR titles? Otherwise I'm sure I'll forget and run > afoul of this again :). Not sure about this. [From the get go, I'm GH averse (reasons not TBD here.] To indirectly answer everyone who gave their (rightful) opinions about why they do what they do, my take is the following, for the components for which I (or lately Alex) do the RM work: * dependencies are upgraded when deemed appropriate by a real developer[1], not a robot, or * dependencies are upgraded to the latest (and only supported) version of the component in question, as preparation for the release. Regards, Gilles [1] Who is involved in the ongoing work of modularizing Commons Math (which is how the dependencies in question have come about). It is a (good) side-effect of the modularization initiative that more automation is possible, but what I actually mean is that whenever any math-related component is released, a post-release task _should_ be performed: upgrade all other math-related components that depend on it. Sometimes this is forgotten. Sorry about that. And Gary will be right to say that it's what "Dependabot" is for... ;-) So indeed, I'd prefer a "reminder" (automated or not), in case we forgot that post-release step (that should be considered mandatory in the math-related components "ecosystem"). Also, that step _must_ be trivial because one of the pre-release step should be to ensure that the newest release does not unintentionally break any of its dependents (and if it does it intentionally, then corresponding JIRA tickets must be filed in each dependent's project). --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
