You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shawn Heisey <ap...@elyograg.org> on 2019/11/13 17:34:23 UTC
Do we want to pursue an LTS designation?
We've had somebody on the Solr mailing list asking questions about our
LTS version.
The thing about this is that we don't really HAVE an LTS version. Our
major version release pace and the way we deal with older branches mean
that a single major version branch is never in a given state for long
enough to really qualify as "long term".
The 7.x branch is in maintenance mode, so most problems that people
encounter with it will only be addressed in a future 8.x version. In my
mind, that means it doesn't qualify as LTS. The current stable branch
is always getting new features, which I think disqualifies that branch
for the LTS label.
The tomcat project has an interesting way of determining when support
ends. Here's a message outlining it:
https://markmail.org/message/6wycxatwzwycmf43
My question is: Do we want to change what we do here, or are we happy
with the current model? If we did change it, I'm not completely sure
what that would look like.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Jörn Franke <jo...@gmail.com>.
Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.
> Am 15.11.2019 um 18:50 schrieb Bram Van Dam <br...@intix.eu>:
>
> On 13/11/2019 20:36, Erick Erickson wrote:
>> I have zero interest in having an LTS “policy†that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “supportâ€, long-term or otherwise.
>
> I hope no one is expecting you to put in free support hours based on
> some random LTS designation. And if you're ever in my neck of the woods,
> I'll gladly buy you a couple of beers to thank you for the effort you do
> put in.
>
> It *is* really annoying that there is no better upgrade path than
> "reindex everything and hope for the best". Making it easier to perform
> in place upgrades would probably go a long way in making users happier,
> and would certainly reduce the calls for an LTS version.
>
> I had some time off this week and I spent it poking around at the
> possibility of making index upgrades easier, but I'm afraid I didn't get
> anywhere with it. Too much low level Lucene stuff is involved that I'm
> not familiar with (yet).
>
> - Bram
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P XÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ XÙ[™K˜\XÚK›Ü™ÃBƒB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Jan Høydahl <ja...@cominvent.com>.
I just removed LTS wording from the Solr download page.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 18. nov. 2019 kl. 09:22 skrev Bram Van Dam <br...@intix.eu>:
>
> On 15/11/2019 23:07, Erick Erickson wrote:
>> Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.
>> https://www.youtube.com/watch?v=eaQBH_H3d3g
>
> Thanks, that sounds super useful! I'll look into it.
>
> - Bram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Do we want to pursue an LTS designation?
Posted by Bram Van Dam <br...@intix.eu>.
On 15/11/2019 23:07, Erick Erickson wrote:
> Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.
> https://www.youtube.com/watch?v=eaQBH_H3d3g
Thanks, that sounds super useful! I'll look into it.
- Bram
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Erick Erickson <er...@gmail.com>.
Bram:
Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.
Basically there are several issues we worked out:
1> how to insure that all segments were rewritten
2> If the schema is changing, how to update the collections one at a time even with shared configsets
3> the nuts-and-bolts of the rewriting.
https://www.youtube.com/watch?v=eaQBH_H3d3g
Best,
Erick
> On Nov 15, 2019, at 2:15 PM, Bram Van Dam <br...@intix.eu> wrote:
>
> On 15/11/2019 19:14, Jörn Franke wrote:
>> Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.
>
> Writing the SolrInputDocument to disk would get really expensive really
> quickly.
>
> When all fields are stored it's relatively easy to build a new index
> from an old one. But when you have a any non-stored fields, things
> become a bit less convenient. In some cases you can uninvert the field
> and recreate the content based on the terms used. Still tricky.
>
> A way to perform in-place updates in Lucene would help in this case. But
> that seems hard to implement, and it would only help with this
> particular upgrade problem.
>
> When I have more time I'll keep hacking away on an upgrade tool that
> works for our use-case. If it turns out to be usable for anyone else,
> I'll give it back to the community.
>
> Also; not sure why the MS mail servers are messing up some of my mails.
> Apologies.
>
> - Bram
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Bram Van Dam <br...@intix.eu>.
On 15/11/2019 19:14, Jörn Franke wrote:
> Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.
Writing the SolrInputDocument to disk would get really expensive really
quickly.
When all fields are stored it's relatively easy to build a new index
from an old one. But when you have a any non-stored fields, things
become a bit less convenient. In some cases you can uninvert the field
and recreate the content based on the terms used. Still tricky.
A way to perform in-place updates in Lucene would help in this case. But
that seems hard to implement, and it would only help with this
particular upgrade problem.
When I have more time I'll keep hacking away on an upgrade tool that
works for our use-case. If it turns out to be usable for anyone else,
I'll give it back to the community.
Also; not sure why the MS mail servers are messing up some of my mails.
Apologies.
- Bram
Re: Do we want to pursue an LTS designation?
Posted by Jörn Franke <jo...@gmail.com>.
Well sometimes even reindexing might not always be avoidable when upgrading. However, there should be a more user friendly way. Not every Solr deployment that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL database where the application puts data in Solr, but not outside Solr for the case of reindexing. In those case it would be useful that Solr can (configurable) write the original SolrInputDocument somewhere and this original document can then be user for reindexing in case of major updates.
> Am 15.11.2019 um 18:50 schrieb Bram Van Dam <br...@intix.eu>:
>
> On 13/11/2019 20:36, Erick Erickson wrote:
>> I have zero interest in having an LTS “policy†that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “supportâ€, long-term or otherwise.
>
> I hope no one is expecting you to put in free support hours based on
> some random LTS designation. And if you're ever in my neck of the woods,
> I'll gladly buy you a couple of beers to thank you for the effort you do
> put in.
>
> It *is* really annoying that there is no better upgrade path than
> "reindex everything and hope for the best". Making it easier to perform
> in place upgrades would probably go a long way in making users happier,
> and would certainly reduce the calls for an LTS version.
>
> I had some time off this week and I spent it poking around at the
> possibility of making index upgrades easier, but I'm afraid I didn't get
> anywhere with it. Too much low level Lucene stuff is involved that I'm
> not familiar with (yet).
>
> - Bram
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P XÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ XÙ[™K˜\XÚK›Ü™ÃBƒB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Bram Van Dam <br...@intix.eu>.
On 13/11/2019 20:36, Erick Erickson wrote:
> I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.
I hope no one is expecting you to put in free support hours based on
some random LTS designation. And if you're ever in my neck of the woods,
I'll gladly buy you a couple of beers to thank you for the effort you do
put in.
It *is* really annoying that there is no better upgrade path than
"reindex everything and hope for the best". Making it easier to perform
in place upgrades would probably go a long way in making users happier,
and would certainly reduce the calls for an LTS version.
I had some time off this week and I spent it poking around at the
possibility of making index upgrades easier, but I'm afraid I didn't get
anywhere with it. Too much low level Lucene stuff is involved that I'm
not familiar with (yet).
- Bram
Re: Do we want to pursue an LTS designation?
Posted by Andrzej Białecki <ab...@getopt.org>.
I agree with the removal of LTS designation - there’s no formal commitment from the community to support this or that release for that long.
Even though in practice bug fixes are often backported to older branches that are still widely used, there’s no actual contract to do so, and implying there is one is misleading.
> On 13 Nov 2019, at 22:46, Chris Hostetter <ho...@fucit.org> wrote:
>
>
> : The term LTS is used loosely and we actually do not promise anything. What we say is
> :
> : > 7.7.x Version in the previous major release for bugfixes only (LTS)
> ...
>
> : Being the one coining the LTS phrasing I am not opposed to changing it
> : to something else. But through the years we have used that term I have
> : not seen a lot of such requests.
>
> I didn't realize you had put that up on the site -- it does seem very
> missleading to me as the "LT" in "LTS" is suppose to mean "Long Term" but
> we do not -- in practice or intent -- have any plans as a project to
> support "7.7.x" in particular any longer then we would any other arbitrary
> "latest" minor release.
>
> Nor did we ever give users who initially installed 7.7.0 when it came out
> any reason to think it would be "supported" (and get bug fixes) for a
> "longer term" then a hypothetical 7.8.0 that might have come out a day
> after they installed some 7.7.x, and replace it's row on that page that
> you've labeled "LTS".
>
> We may not have ever gotten questions about it, but that may just be
> because people have very specific assumptions about what it means, and
> never thought to ask questions to verify those assumptions.
>
> I think, given how the project *actually* supports releases, I think we
> should remove references to "LTS" from that page, and leave the other
> description "Version in the previous major release for bugfixes only" as
> it stands -- or perhaps tighten it up even more: "Version in the previous
> major release that may get bug fixs"
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Chris Hostetter <ho...@fucit.org>.
: The term LTS is used loosely and we actually do not promise anything. What we say is
:
: > 7.7.x Version in the previous major release for bugfixes only (LTS)
...
: Being the one coining the LTS phrasing I am not opposed to changing it
: to something else. But through the years we have used that term I have
: not seen a lot of such requests.
I didn't realize you had put that up on the site -- it does seem very
missleading to me as the "LT" in "LTS" is suppose to mean "Long Term" but
we do not -- in practice or intent -- have any plans as a project to
support "7.7.x" in particular any longer then we would any other arbitrary
"latest" minor release.
Nor did we ever give users who initially installed 7.7.0 when it came out
any reason to think it would be "supported" (and get bug fixes) for a
"longer term" then a hypothetical 7.8.0 that might have come out a day
after they installed some 7.7.x, and replace it's row on that page that
you've labeled "LTS".
We may not have ever gotten questions about it, but that may just be
because people have very specific assumptions about what it means, and
never thought to ask questions to verify those assumptions.
I think, given how the project *actually* supports releases, I think we
should remove references to "LTS" from that page, and leave the other
description "Version in the previous major release for bugfixes only" as
it stands -- or perhaps tighten it up even more: "Version in the previous
major release that may get bug fixs"
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Do we want to pursue an LTS designation?
Posted by Jan Høydahl <ja...@cominvent.com>.
The term LTS is used loosely and we actually do not promise anything. What we say is
> 7.7.x Version in the previous major release for bugfixes only (LTS)
In practice 7.7.x will now only get critical security related releases and not ordinary bugfixes, unless someone volunteers to RM such a release.
8.x.x will likely get more bugfix releases after release of 9.0 since there is a Java upgrade requirement.
Being the one coining the LTS phrasing I am not opposed to changing it to something else. But through the years we have used that term I have not seen a lot of such requests.
This is probably a good time to challenge one of you to go clone our new website repo at https://github.com/apache/lucene-site <https://github.com/apache/lucene-site>, make a change, build the site locally and submit a PR :) It is actually quite pleasant!
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 13. nov. 2019 kl. 21:15 skrev Adam Walz <ad...@adamwalz.net>:
>
> It looks like solr 7.7.x is currently designated as the LTS version on the website. https://lucene.apache.org/solr/downloads.html <https://lucene.apache.org/solr/downloads.html>
> On Wed, Nov 13, 2019 at 11:36 AM Erick Erickson <erickerickson@gmail.com <ma...@gmail.com>> wrote:
> I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.
>
> Best,
> Erick
>
> > On Nov 13, 2019, at 12:34 PM, Shawn Heisey <apache@elyograg.org <ma...@elyograg.org>> wrote:
> >
> > We've had somebody on the Solr mailing list asking questions about our LTS version.
> >
> > The thing about this is that we don't really HAVE an LTS version. Our major version release pace and the way we deal with older branches mean that a single major version branch is never in a given state for long enough to really qualify as "long term".
> >
> > The 7.x branch is in maintenance mode, so most problems that people encounter with it will only be addressed in a future 8.x version. In my mind, that means it doesn't qualify as LTS. The current stable branch is always getting new features, which I think disqualifies that branch for the LTS label.
> >
> > The tomcat project has an interesting way of determining when support ends. Here's a message outlining it:
> >
> > https://markmail.org/message/6wycxatwzwycmf43 <https://markmail.org/message/6wycxatwzwycmf43>
> >
> > My question is: Do we want to change what we do here, or are we happy with the current model? If we did change it, I'm not completely sure what that would look like.
> >
> > Thanks,
> > Shawn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>
>
>
> --
> Adam Walz
Re: Do we want to pursue an LTS designation?
Posted by Adam Walz <ad...@adamwalz.net>.
It looks like solr 7.7.x is currently designated as the LTS version on the
website. https://lucene.apache.org/solr/downloads.html
On Wed, Nov 13, 2019 at 11:36 AM Erick Erickson <er...@gmail.com>
wrote:
> I have zero interest in having an LTS “policy” that requires any further
> commitment of my personal time to random people who ask for it but aren’t
> willing to pay. I consider my non-paid work to Solr a _volunteer_ activity,
> not something anyone has a right to demand as “support”, long-term or
> otherwise.
>
> Best,
> Erick
>
> > On Nov 13, 2019, at 12:34 PM, Shawn Heisey <ap...@elyograg.org> wrote:
> >
> > We've had somebody on the Solr mailing list asking questions about our
> LTS version.
> >
> > The thing about this is that we don't really HAVE an LTS version. Our
> major version release pace and the way we deal with older branches mean
> that a single major version branch is never in a given state for long
> enough to really qualify as "long term".
> >
> > The 7.x branch is in maintenance mode, so most problems that people
> encounter with it will only be addressed in a future 8.x version. In my
> mind, that means it doesn't qualify as LTS. The current stable branch is
> always getting new features, which I think disqualifies that branch for the
> LTS label.
> >
> > The tomcat project has an interesting way of determining when support
> ends. Here's a message outlining it:
> >
> > https://markmail.org/message/6wycxatwzwycmf43
> >
> > My question is: Do we want to change what we do here, or are we happy
> with the current model? If we did change it, I'm not completely sure what
> that would look like.
> >
> > Thanks,
> > Shawn
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Adam Walz
Re: Do we want to pursue an LTS designation?
Posted by Erick Erickson <er...@gmail.com>.
I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or otherwise.
Best,
Erick
> On Nov 13, 2019, at 12:34 PM, Shawn Heisey <ap...@elyograg.org> wrote:
>
> We've had somebody on the Solr mailing list asking questions about our LTS version.
>
> The thing about this is that we don't really HAVE an LTS version. Our major version release pace and the way we deal with older branches mean that a single major version branch is never in a given state for long enough to really qualify as "long term".
>
> The 7.x branch is in maintenance mode, so most problems that people encounter with it will only be addressed in a future 8.x version. In my mind, that means it doesn't qualify as LTS. The current stable branch is always getting new features, which I think disqualifies that branch for the LTS label.
>
> The tomcat project has an interesting way of determining when support ends. Here's a message outlining it:
>
> https://markmail.org/message/6wycxatwzwycmf43
>
> My question is: Do we want to change what we do here, or are we happy with the current model? If we did change it, I'm not completely sure what that would look like.
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org