looks like it's a good time for me to remind how we need commits
managed, and their relation to JIRA tickets.
When reviewing pull requests, and before merging them, please pay
attention to these simple rules as it's important for long term
We need to be able to query JIRA to figure out which branches and
versions contain a specific patch; it's also useful for people to know
if they might be affected by a specific bug.
# Commit format
ALL commits need to start with the JIRA code which relates to the change.
This implies that any little improvement needs a JIRA ticket created
before being integrated; this is sometimes a little inconvenient, but
please stick to it the same.
The exception to this rule is the release process itself; it's ok for
scripts to push placeholder commits to help identify just-before and
# Closed JIRA tickets
One should never have a new commit which is recycling a JIRA ticket
which is closed already.
A closed ticket for us means "sealed and archived".
This means that if you discover a better way to fix an issue which is
already closed, you will need to open a new JIRA.
Even if technically the old issue had not been fixed properly, we
don't re-open it as it represents a specific changeset which was
already included in a published release: a published release either
contains a changeset (a patch) or it doesn't - we can't manage
situations well such as "it had half a fix".
# Keep unrelated commits separated
For as much as possible, when fixing an issue try to focus on the
individual issue exclusively.
If you notice an opportunity for refactoring related code, it's ok to
include it. But if you notice such opportunities, typos, or have a
general urge to rewrite code which isn't necessarily useful to touch
during the main patch you're working on - then please make this a
separate JIRA and a separate set of commits.
That said, we're very reasonable. Including two kinda related
changesets in a same PR is ok, especially if one depends on the other.
Including a single typo fix is ok. Sending a "follow-up" PR for a fix
which was just merged is fine to reuse the same JIRA - as long as it
wasn't released yet (and closed).
Also, opening a JIRA doesn't have to take much of your time. We don't
require many fields to be filled, and for simple issues it's totally
ok to have a short description. You can also learn its shortcuts, or
use scripts / command line tools to interact with it, integrate it
with your IDE.
I'll update the CONTRIBUTING.md as I see we could clarify some of
these points there.
We just published Hibernate Search 6.0.0.Beta10.
This release mainly brings a total hit count threshold, conditional
indexing, better timeouts, and per-index analyzer definitions for
It also includes an upgrade to Lucene 8.6.1, Elasticsearch 7.9.0 and
Hibernate ORM 5.4.21.Final.
For more information, see our blog:
The metamodelgen project has since many years been incorporated in
ORM, so we archived the old repository; the idea was triggered by
contributors sending patches to the wrong codebase.
FYI I've also deleted the maintenance team from Github :
metamodelgen-dev ; it had only Gunnar and Emmanuel in it.