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 wrote:
>
> R
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 1:58
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 ve
> 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 wa
> 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
Hostetter 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 end up with on
> : the JIRA - master (8.0
: 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, as
; 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
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
on 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.0), 7.1,
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 == on
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 somethi
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?
-An
[
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
[
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
cket:
* SOLR-8566: 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 V
first apache git commit.
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/b
rge in revision 1725752 from trunk)
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-
mmit 1725752 from [~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
initialCapacity tweak.
* ManagedResource.storeManagedData log.error tweak ("load data" instead of
"load stop words").
> umbrella ticket: various initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
mmit 1725471 from [~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 Ve
mmit 1725469 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1725469 ]
SOLR-8566: TransformerFactory.defaultFactories initialCapacity tweak
> umbrella ticket: various initialCapacity tweaks (Fix Ve
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
ous initialCapacity tweaks (Fix Versions: trunk 5.5)
> -
>
> Key: SOLR-8566
> URL: https://issues.apache.org/jira/browse/SOLR-8566
> Project: Solr
>
26 matches
Mail list logo