When will Lucene 4.8.0 be released?

[zhangbaodan]

I saw that Lucene 4.8.0 is currently the beta version, may I ask when the release version will be released?

[nikcio]

This question is similar to what is found in: #437 (comment)

But I too would like to know which issues are blockers for a release version of Lucene 4.8.0. I see in the comment linked above there's some issues linked. But it might be an idea to have a pined issue with the roadmap/issue tracker for the next release version.

I don't know if the milestone is up to date but if this is the preferred way to showcase issues needing to be solved before a release version then an issue could just be a short description followed by a link to the milestone.

Otherwise an issue with a list of issue links would also be great. For example:

Title Lucene 4.8.0 progress (Roadmap)
Content:

Blockers:
- Issue 1
- Issue 2

High priority
- Issue 1
- Issue 2

Normal priority
.... And so on

What do you think @NightOwl888? I think this will be a recuring question until a non beta version is released 😄. Might also help other people find task to help out on?

[jeme]

AFAIK it is the milestone, @NightOwl888 has been trying to keep it under the milestone: https://github.com/apache/lucenenet/issues?q=is%3Aopen+is%3Aissue+milestone%3A4.8.0

@NightOwl888 Feel free to correct me if that is incorrect :)

[NightOwl888]

That is correct for the most part. There have been several newer issues added that don't have a 4.8.0 milestone that probably should, though.

Trying to determine exactly what is blocking the release requires analysis to work out, which makes a list like that a lot of work to maintain. For sure we have a blocker if:

1. The solution to the issue requires a breaking API change. See Changes that affect compatibility.
2. The solution to the issue requires a breaking behavioral change.
3. It is a high priority bug

NOTE: In general, we shouldn't have any breaking binary changes because for the most part we are using the same binary formats as Lucene. That said, there is an open task to add tests to verify 2-way compatibility, as this hasn't been run for several years and there have been a large number of changes since then.

If the feature requires an additive change, it can generally wait unless the priority is high (normal and low priority are not blockers, but are "could haves" that would be accepted if submitted as PRs).

Reviewing tests is blocking the release. The tests we have reviewed so far have revealed that we are missing asserts and other test features. They have also revealed several other usability issues that need to be addressed, and I suspect the review may bring up a few more of those issues.

And of course, making ICU4N stable is also still a blocker (unless we opt to delay release of everything that depends on it). All of our other dependencies are stable, but some have up-for-grabs tasks that would be nice additions to have. For example, neither ICU4N or J2N have API documentation websites even though the APIs are extensively documented as XML doc comments. I suspect if we had documentation, people would be more likely to find and report behaviors that conflict with the documentation (i.e. bugs). So, while the documentation is not blocking the release, adding it would help us track down issues that may be.

In general, anything that is using the Future milestone can wait until after the release.

[paulirwin]

See #793 for the latest updates.