: Okay, so how do we want to handle changelog entries for these from : Solrbot? I want to draw attention to this conversation: : https://github.com/apache/solr/pull/4842#pullrequestreview-5077496282 …
Strawman proposal from someone who doesn't really know how solrbot works... 1) Change it to stop putting the PR# and and version details in the changelog/unreleased/ file *name* 2) It should just create file names like "dep-update__google-errorprone.yaml" (that match the version key in libs.versions.toml) 3) if a file with the same name already exists in changelog/unreleased/ , it should just overwrite it completely. 4) if it updates 50 deps in a single PR, there should be 50 files created in changelog/unreleased/ 5) humans doing manual dependency updates should follow the same practice ...in theory, this leaves us with a situation where automated changelog generation "just works" in terms of ensuring that we get a clean "Dependency Upgrades" section that lists every dependency that was upgraded since the last release -- but each dependency is listed no more then once, listing the "latest" version it was upgraded to. If we don't feel like *every* dependency is worthy of having it's upgrad mentioned in the changelog, then there should be some way to annotate the "important" dependencies (so both humans & solrbot can tell which ones are worth documenting) and precommit should fail if a file in changelog/unreleased/ exists named after a non-important dependency. is that viable ? -Hoss http://www.lucidworks.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
