My understanding from what I have heard over the past year:
1. Reporting of issues (bugs) can be on any release or branch or trunk.
Testing on the other releases, branches, or trunk is encouraged, but not
mandatory. The main thing is to capture a repro scenario.
2. Any bug fixes should be on: 1) trunk, 2) branch_5x, and 3) branch_4x - to
all that the bug applies to.
3. Any new features should be first on trunk and given time to bake (i.e.,
fix any Jenkins errors), then backported to branch_5x as the feature is
completed and debugged. A determined effort must be made to keep "the stable
branch" as stable as possible.
-- Jack Krupansky
-----Original Message-----
From: Shawn Heisey
Sent: Friday, November 21, 2014 3:36 PM
To: dev@lucene.apache.org
Subject: Re: Testing Solr 5
On 11/21/2014 1:14 PM, Alexandre Rafalovitch wrote:
I am writing something that - will - depend on Solr 5. As I usually
work with released versions, I am not entirely sure of the correct
workflow.
I can check out branch_5x and do my research against that. I assume
that's the correct source for what will land in version 5.
But if I find an issue, do I then report it against 5? Or do I need to
retest that against trunk and report against trunk? I don't know how
in-sync these two are at this point.
I've checked https://wiki.apache.org/solr/HackingSolr but it is not
specific enough (and is actually out of date regarding version 5).
Any testing we do for branch_5x probably isn't enough, so please do test
with it. That is the branch where development will happen for all 5.x
releases. If you do find a problem and *can* try again with trunk,
please do, but don't make that a prerequisite for filing an issue or
creating a patch. A patch against trunk is preferred, but any patch is
better than none.
We'd like to know which branch the patch applies to, and if there are
any problems we may need to know the SVN revision number, so it's better
to include that info up front if you have it. If you are using one of
the git mirrors, the SVN revision number may not be available. The git
commit hash may be useful instead.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
