Makes sense, as long as we don’t treat it as ‘optional’ in the literal sense.
We should try and put in some affected version there for the bug fixes as this
entry certainly doesn’t make sense for anything other than the bugs.
-Anshum
> On Jul 10, 2017, at 12:48 PM, David Smiley
RE *Affected Versions*. "All ..." seems wrong. to clarify, this is an
optional entry and shouldn't imply an exhaustive list. The submitter and
anyone helping can put the known version (bug experienced in version X for
sure) and/or perhaps the earliest known/believed.
On Mon, Jul 10, 2017 at
As long as all of us agree, and try to use the same system, I think we'll be
fine.
I think there's a reasonable consensus on the following understanding of
"fixVersion/s", and "Affected Versions"
- fixVersion: All branches that the code was committed. Example, assuming that
the last released
> But for new features, it is different. The CHANGES entry is only added to
> the first version the feature was introduced (e.g. 7.0.0), even if the
> feature is committed to master, branch_7x, branch_7_0. In my head it would
> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
I
I agree that it makes sense for bug fixes to list all versions (branches) the
fix was applied; we’ll also add CHANGES entry under the same version headings,
except for unreleased versions.
But for new features, it is different. The CHANGES entry is only added to the
first version the feature
> As David mentioned, there isn’t a
> single true ‘solution’ for this problem so the more information we provide
> the better.
Think of it in terms of how your repository is structured:
This issue was *fixed* on git branches [x,y,z] and *affected* tags [a,b,c].
This gives a clear an unambiguous
s Hostetter <hossman_luc...@fucit.org> wrote:
>
>
> : Here’s my issue with that approach. Say I commit something that would be
> : released with 7.0 but obviously, I also commit to master at this point.
> : Going with your approach here are the fix versions I’ll
: Here’s my issue with that approach. Say I commit something that would be
: released with 7.0 but obviously, I also commit to master at this point.
: Going with your approach here are the fix versions I’ll end up with on
: the JIRA - master (8.0), 7.1, and 7.0.
:
: This confuses me
pproach. Say I commit something that would be
> released with 7.0 but obviously, I also commit to master at this point. Going
> with your approach here are the fix versions I’ll end up with on the JIRA -
> master (8.0), 7.1, and 7.0.
>
> This confuses me, as anything that has a
ly.
>>
>> @Erick
>> Here’s my issue with that approach. Say I commit something that would be
>> released with 7.0 but obviously, I also commit to master at this point.
>> Going with your approach here are the fix versions I’ll end up with on the
>> JIRA - *master (8.0), 7
rpreting the fixVersion differently.
>
> @Erick
> Here’s my issue with that approach. Say I commit something that would be
> released with 7.0 but obviously, I also commit to master at this point.
> Going with your approach here are the fix versions I’ll end up with on the
> JIRA - *master (8
that would be
released with 7.0 but obviously, I also commit to master at this point. Going
with your approach here are the fix versions I’ll end up with on the JIRA -
master (8.0), 7.1, and 7.0.
This confuses me, as anything that has a 7.0 fix version shouldn’t have
anything else from the 7x line
I'm just including a fix version for each push I make. I.e.
If I push to master I'll add "master (8.0)".
If I push to 7x, at this point I'll add 7.1
If I push to 7_0 I'll add 7.0
If I push to 6x I'll add 6.7
If for some reason I wanted to push it to branch_6_6 I'd add 6.6.1
I think one push ==
There's been a fairly recent discussion about it on the mailing list
(David Smiley and were involved in that discussion, among other
people). There are many different takes on how to handle fix-for and
branches. I don't think we can find the "best" strategy, although
perhaps we can agree on
Hi,
I was a bit confused in terms of setting the ‘fix version’ for JIRAs that are
being committed right now. I think it makes sense for the fixVersion to just be
7.0, and nothing else for everything that is going into branch_7_0, instead of
being both 7.0, and master (8.0).
Any thoughts?
[
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved SOLR-8566.
---
Resolution: Fixed
> umbrella ticket: various initialCapacity tweaks (Fix Versi
first apache git commit.
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/b
: SyncStrategy.syncWithReplicas initialCapacity tweak
** master/trunk:
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2782f607
** branch_5x: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/6234a115
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk
[
https://issues.apache.org/jira/browse/SOLR-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-8566:
--
Summary: umbrella ticket: various initialCapacity tweaks (Fix Versions:
trunk/master 5.5
)
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Pro
initialCapacity tweak.
* ManagedResource.storeManagedData log.error tweak ("load data" instead of
"load stop words").
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
[~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1725752 ]
SOLR-8566: ManagedResource.buildMapToStore initialCapacity tweak.
ManagedResource.storeManagedData log.error tweak ("load data" instead of "load
stop words").
> umbrella ticket: various initialCapacity twea
ous initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>
Christine Poerschke created SOLR-8566:
-
Summary: umbrella ticket: various initialCapacity tweaks (Fix
Versions: trunk 5.5)
Key: SOLR-8566
URL: https://issues.apache.org/jira/browse/SOLR-8566
[~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1725469 ]
SOLR-8566: TransformerFactory.defaultFactories initialCapacity tweak
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk
[~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1725471 ]
SOLR-8566: TransformerFactory.defaultFactories initialCapacity tweak (merge in
revision 1725469 from trunk)
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk
26 matches
Mail list logo
