Absolutely.
What I was trying to say is that when it comes to implementation,
there may be a choice of strategies to do so within the same scope. A
strategy that aligns better with something that - with more work -
eventually becomes true structured data may have more long-term value
than a
>
> > Q: Should we create a separate JIRA for these contribs... or ditch JIRA
> entirely for them, relying on GitHub alone?
>
> I'd start with same JIRA, with a separate component or label. I don't
> think GH issues would be good because it becomes harder to link between
> core and contrib issues
I'd rather not scope-creep my proposal here further. Granted I ventured
into TXT -> Markdown.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Nov 24, 2020 at 9:37 AM Alexandre Rafalovitch
wrote:
> And - afterthought - if there is an easily
And - afterthought - if there is an easily parsable format, the parser
could even run at the commit time on GitHub to make sure that issue
numbers are correct, names are included and formatting is not broken.
Regards,
Alex.
On Mon, 23 Nov 2020 at 19:38, Alexandre Rafalovitch wrote:
>
>
On Tue, Nov 24, 2020 at 3:24 AM Bram Van Dam wrote:
> Is there any particular reason why the IndexUpgrader couldn't simply
> warn about non-upgradable changes? If you have a data type that's no
> longer supported and there's no migration path: error out.
>
> I understand the whole "x != f(x)"
On 20/11/2020 19:18, Uwe Schindler wrote:
> Thanks for bringing this again.
>
> I tend to say: Let us just allow also IndexUpgrader beyodn 2 versions! If
> somebody complains about incorrect offsets, oh man - It's their problem.
Is there any particular reason why the IndexUpgrader couldn't
