[
https://issues.apache.org/jira/browse/SOLR-14824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198162#comment-17198162
]
Dawid Weiss commented on SOLR-14824:
------------------------------------
bq. The usecase here is that on "branch_9_7" regardless of whether
'baseVersion' is 9.7.0, or 9.7.1, etc... (making the default "version"
9.7.0-SNAPSHOT, 9.7.1-SNAPSHOT, etc..), we want to be able to "build" the "9.7"
ref-guide, and by default the builds should be "-DRAFT" but optionally a
committer should be able to indicate that it's "non-DRAFT" so they can
(re-)publish it to the site.
Right. This is relevant to the discussion I had with Uwe about having a
"release" commit where the version would be actually fixed (not provided on
command-line during release). I accept his argument that this increases chances
of accidentally building a "release" build by a third-party (although I
disagree this is harmful - if somebody does it, so be it?). In the above case I
think it'd be consistent with the "release procedure" to have the same argument
passed on command line. If somebody wishes to release a non-draft
(non-snapshot?) version of the guide, they would use the same syntax as when
compiling release artifacts. Think this way: even if somebody doesn't know
about the ref guide and runs top-level "assemble everything in version X" then
the guide would be compiled with an appropriate non-version status. Does this
make sense?
> Simplify set of Ref Guide build parameters
> ------------------------------------------
>
> Key: SOLR-14824
> URL: https://issues.apache.org/jira/browse/SOLR-14824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
> Reporter: Cassandra Targett
> Assignee: Chris M. Hostetter
> Priority: Minor
> Attachments: SOLR-14824.patch, SOLR-14824.patch, SOLR-14824.patch
>
>
> While trying to solve LUCENE-9495, I thought it might be a good idea to try
> to simplify the set of variables and properties used during the Ref Guide
> build.
> There are 3 areas to work on:
> 1. Remove the "barebones-html" build. With Gradle the build is self-contained
> and {{gradlew check}} and {{gradle precommit}} could just build the full docs
> and check them.
> 2. Remove some properties that only existed for a hypothetical need related
> to the now-removed PDF.
> 3. Change remaining properties to be defined directly in build.gradle instead
> of relying on ant properties functionality.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
