[hibernate-dev] Why backports to Hibernate Search 4.4 branch?

[Sanne Grinovero]

I've been asked on github's review comments why I'm still backporting
trivial fixes to the 4.4 branch;
moving the conversation to the mailing list:

We created the 4.5 branch because it was impossible to support both
ORM series 4.2 and 4.3, so a 4.5 release train was highly needed to
not prevent people to move onto WildFly and our latest ORM versions.

Still considering that JPA 2.1 is very new, I think it's fair to state
that our largest pool of users is using JPA 2.0 at present; of course
I'm not counting those on very old unmaintained versions as they are
unlikely to download a new version of Search or reported any issue
anyway.

So there still is a large interest, not least some of our very best
contributors, presently using ORM 4.2 and JPA 2.0, AND actively using,
debugging and reporting issues on Hibernate Search 4.4 (see for
example Guillaume's email of today).

Also, we have products to support for a very long term which are based
on this stable 4.4 branch: backporting occasional trivial issues makes
our maintenance capabilities better.

We don't promise that all fixes will be backported, and we'll probably
apply fixes only "as needed" by a specific request, but if there is
something which is definitely broken and so trivial to fix like [1], I
simply think it's easier to cherry-pick right away rather than
tracking some additional TODOs ;-)

It is also possible that we'll do more 4.4 releases as needed. Of
course I don't wish to spend too much of our effort on it, but if it's
an easy task, I don't see why we should deny it.
[Finally, I'm taking organizational steps to make such releases have
no impact on our time, so it's a win-win for everyone.. more news to
follow]

Cheers,
Sanne

1 - https://github.com/Sanne/hibernate-search/commit/f34a61e90b7dbec38a01f0a7d612e21423ba0e58