[
https://issues.apache.org/jira/browse/SOLR-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266584#comment-14266584
]
Hoss Man commented on SOLR-6871:
--------------------------------
bq. ... folks making these changes can't edit the currently live
quickstart.html file because it, by design, is suppose to be reflecting what
happens if folks are trying out the examples in the "current release" (4.10.2)
branching the website might be a way of addressing this type of "edits not
ready to be live" but wouldn't help with the larger issue of having 2 versions
of the tutorial "live" for users at the same time during periods when we are
supporting multiple versions: ie: having a way for people to find the 4.10
quickstart content right after 5.0 is released -- similar to how the live
site's "tutorial.html" looked when 4.0 came out...
https://svn.apache.org/viewvc/lucene/cms/trunk/content/solr/tutorial.mdtext?revision=1436785&view=markup&pathrev=1638603
...i know there has also been talk in other issues about wanting to include
multiple tutorials beyond the "quickstart" (SOLR-6078, SOLR-6748, SOLR-6080,
SOLR-6079, etc...) so all of those will have the same "versioning" issues as
the current quickstart content.
> Need a process for updating & maintaining the new quickstart tutorial (and
> any other tutorials added to the website)
> --------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6871
> URL: https://issues.apache.org/jira/browse/SOLR-6871
> Project: Solr
> Issue Type: Task
> Reporter: Hoss Man
> Priority: Blocker
> Fix For: 5.0
>
>
> Prior to SOLR-6058 the /solr/tutorial.html link on the website contained only
> a simple landing page that then linked people to the "versioned" tutorial for
> the most recent release -- or more specificly: the most recent release*s*
> (plural) when we were releasing off of multiple branches (ie: links to both
> the 4.0.0 tutorial, as well as the 3.6.3 tutorial when 4.0 came out)
> The old tutorial content lived along side the solr code, and was
> automatically branched, tagged & released along with Solr. When committing
> any changes to Solr code (or post.jar code, or the sample data, or the sample
> configs, etc..) you could also commit changes to the tutorial at th same time
> and be confident that it was clear what version of solr that tutorial went
> along with.
> As part of SOLR-6058, it seems that there was a concensus to move to a
> keeping "tutorial" content on the website, where it can be integrated
> directly in with other site content/navigation, and use the same look and
> feel.
> I have no objection to this in principle -- but as a result of this choice,
> there are outstanding issues regarding how devs should go about maintaining
> this doc as changes are made to solr & the solr examples used in the tutorial.
> We need a clear process for where/how to edit the tutorial(s) as new versions
> of solr come out and cahnges are made that mandate corisponding hanges to the
> tutorial. this process _should_ also account for things like having multiple
> versions of the tutorial live at one time (ie: at some point in the future,
> we'll certainly need to host the "5.13" tutorial if that's the current
> "stable" release, but we'll also want to host the tutorial for "6.0-BETA" so
> that people can try it out)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
