[
https://issues.apache.org/jira/browse/SOLR-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928155#comment-15928155
]
Christine Poerschke commented on SOLR-10294:
--------------------------------------------
I would also favour a "docs-with-code" approach including merging "backwards"
from master into the upcoming release branch e.g. branch_6x.
For docs (but not code) to follow a merging "forward" from branch_6x into
master when it's time for the next major version seems counter-intuitive and
could be building up merge trickiness, trickiness which if tackled on an
as-we-go-along basis should be more manageable.
> Decide branching strategy for Ref Guide
> ---------------------------------------
>
> Key: SOLR-10294
> URL: https://issues.apache.org/jira/browse/SOLR-10294
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Cassandra Targett
>
> Since one of the reasons to move off Confluence is to provide online docs for
> specific versions of Solr, we should agree up front how we'll manage working
> with the branches.
> There are two general proposals on the table so far:
> # Make all changes in 'master' (trunk) and backport to branches for
> releasing the content. We'd need to merge "backward" into upcoming
> release branch.
> # Make all changes in branch_6x (or branch_7x, etc.) and only move
> things to master when they are only applicable to unreleased next
> major version. We'd merge 6x "forward" when it's time for next major
> version.
> Some discussion on this started in the mailing list, so I'll copy the
> feedback received so far on this as comments to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
