lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cassandra Targett (JIRA)" <>
Subject [jira] [Commented] (SOLR-10294) Decide branching strategy for Ref Guide
Date Wed, 15 Mar 2017 19:58:41 GMT


Cassandra Targett commented on SOLR-10294:

>From [~janhoy] (devs@lucene email 13 Mar 2017, Re: Moving the Ref Guide: Progress Update
& Next Steps):

And agree with Hoss that docs must be expected with code, or else the released git version
will not contain the correct refguide. We cannot rely on releasing the refguide weeks after
the code anymore, and we can’t hold up the release process and do tons of re-spins for simple
adoc changes.

> Decide branching strategy for Ref Guide
> ---------------------------------------
>                 Key: SOLR-10294
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message