Who said anything about blocking progress? All I'm saying is that before we release these improvements, we need to have a migration plan. These are not just my customers. I think that there are other people that use this module, at least from questions that pop up here and there on the list.
Sure, we can tell everyone to re-index. But that's not how I prefer to work. I don't think that cutting over to DV is the only migration we should talk about. E.g.
LUCENE-4623 would also require migration and any change in the future to how we decide to store/encode facets would require migration.
It would be good if we can think about a layer that will provide that migration. Today we have Codecs and Lucene guarantees that old segments will be read w/ old Codecs versions (per our back-compat policy). What I would like to develop is something similar, which can read facets from old segments in the old way, and ultimately when segments are merged, migrate data to the new format. Then we can tell customers that if they didn't migrate their indexes when Lucene 6.0 is released, they have to addIndexes or forceMerge or something.
I know that this module has the @lucene.experimental tag on it all over the place, but I don't treat it as experimental at all. I would prefer that you help me develop this migration layer, even if just by contributing ideas, rather than tell me that it's my problem and that I get paid to solve it .
I don't think that we should release code that breaks all apps out there and forces them to reindex. Unless the changes are really non-migratable. But in this case, I think it should be easy? If you want to chime in, I'll open a separate issue to discuss this.