janhoy commented on a change in pull request #469:
URL: https://github.com/apache/solr/pull/469#discussion_r774011189
##########
File path: dev-tools/scripts/addVersion.py
##########
@@ -44,10 +44,9 @@ def edit(buffer, match, line):
print('done' if changed else 'uptodate')
def add_constant(new_version, deprecate):
- # TODO: Modify for new SolrVersion class, see SOLR-15845
- filename = 'lucene/core/src/java/org/apache/lucene/util/Version.java'
+ filename = 'solr/core/src/java/org/apache/solr/util/SolrVersion.java'
Review comment:
This is completely untested. Will probably get to it during the 9.0
release, but if anyone facies to review, go ahead.
Or if anyone knows of a better way for Solr to manage its own version than a
SolrVersion class with enums, that could also be a way to go. Perhaps we could
use code generation from gradle to insert the version somewhere and parse that
statically. This huge version class seems a bit overkill imo. I also know there
are various Java implementations of SemVer classes out there that could be used
instead.
--
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
