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

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/f34a61e90b7dbec38a01f0a7...