[
https://issues.apache.org/jira/browse/SOLR-14824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198467#comment-17198467
]
Chris M. Hostetter commented on SOLR-14824:
-------------------------------------------
{quote}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?
{quote}
(NOTE: I'm going to assume "non-version" was a typo/brain-fart and you meant
"non-DRAFT" because otherwise i really have no idea what you ment)
I'm don't think what you're suggesting really makes sense in terms of the
ref-guide – because when you talk about "release procedure" and "version X"
what you're talking about is "ARTIFACT release procedure" and "version X.Y.Z" –
where the artifacts are uploaded to dist.apache, frozen and immutable and the
only way to "update" them is to do a new release of X.Y.(Z+1).
But for the ref-guide we don't have "released" artifacts that are frozen in
time (we use to, we stoped, and cleaning up the build cruft related to them is
a big part of this issue) – we might "publish" (to the website) a non-draft
"ref-guide X.Y" to the website, and then a week, or a month later someone might
notice a very missleading mistake, or typo in the markup that causes a
malformed and unreadable example, and we might fix that on branch_X_Y and
republish "ref-guide X.Y" to the exact same URL on the website ... and that
would all be independent of whether there has been a "release" of Solr X.Y.1,
or X.Y.0, etc... from that branches in the mean time.
Even if someone doesn't know about the ref-guide, but they checkout the the
release commit/tag for "X.Y.0" and run the "assemble everything" (setting
whatever property they may need to set to mark it as 'official' and
'non-SNAPSHOT') that doesn't mean the ref-guide they find in the build
directory should be a 'non-DRAFT' "ref-guide X.Y" because there may be
corrected content for "guide version X.Y" on branch_X_Y _after_ that release
commit.
To go back to your question from the other day, which i realize I responded to
but didn't directly answer..
{quote}If this draft status is related to version then it could be
automatically detected (version.contains("SNAPSHOT")).
{quote}
No. The "draft status" is not related to the version. Not in the sense of the
'$version' variable in the top level build.gradle (either hardcoded or derived
from commad line props), nor in the sense of the '$solrDocsVersion' variable in
the ref-guide build (with the patch applied).
The only thing that determines whether a ref-guide build is a DRAFT or not, is
if it is currently being built by a committer, who has the intent of uploading
it to the website and considers the content to no longer be DRAFT.
> 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: [email protected]
For additional commands, e-mail: [email protected]
