HoustonPutman commented on PR #1068: URL: https://github.com/apache/solr/pull/1068#issuecomment-1285712667
Hey Christine, I appreciate the thought here, but I'm not sure its actually the logic that we want. The `antora.yaml` file is used to generate the official ref guide for that branch, so for `main` and stable branches (`branch_9x`, `branch_10x`, etc), this is probably a good check. It's fine to update these at any time because there are no actual releases for these branches, just nightly builds of the ref-guide. However for the release branches (`branch_9_0`, `branch_9_1`), we only want to update the `antora.yaml` on release, because they represent the official ref guide for the latest release of that minor version. So let's say that Solr 9.2.0 uses Lucene 9.5.0, there is a bug discovered in Lucene 9.5.0 so 9.5.1 is released. If we then go update `branch_9_2` to use Lucene 9.5.1, we do not want the official ref guide to say that Solr `9.2.0` is using Lucene `9.5.1`. So while for the vast majority of the time this check is good, it's not 100% of the time. So we probably shouldn't bake it into the precommit command. On a side note, there is a task `gradle setOfficialAntoraYaml` that will re-generate this file with all correct changes. (This is used as a part of the releaseWizard process). I will add some text to the top of the antora.yaml that spells this out better. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
