Huge Project, Small Team

Hibernate is a huge Open Source project (multiple projects, really). And yet its core development team is amazingly small. Which means that we need to pick our battles...

Maintain latest major version

One of the major low-hanging fruits for us in this regard is to maintain just the most recent major release. A major release for us in this regard is the first two digits of the release version (4.0, 4.1, 4.2. 4.3, 5.0, etc). At the time of this writing, e.g., 5.0 has just recently "gone Final" meaning that it is now the current major version. So effectively this means that we no longer consider bugs reported against versions prior to 5.0. When 5.1 goes Final, it will now become the current major version and we will only consider bugs reported against it. And so on..

What this means in practice is that for bug reports and to a degree enhancement requests (as separate from new feature requests) we only focus on reports that affect the current major release. After that "switch over point" there would no longer be any releases of the previous current major versions. We may or may not continue to port work to the underlying branch in the GitHub repo for the previous version; it is best not to rely on that.

Implication on Pull Requests

Given this guideline, you may wonder what happens to Pull Requests against no-longer maintained branches. For example, in the scenario above where 5.0 has just gone final, what happens to Pull Requests (and their Jira issues) that targeted 4.3 or earlier?

Pull requests against 4.3 (or earlier) that were created before 5.0 went final will be placed into a special bucket in Jira indicating that they have a test and fix pull request associated with them.

Pull requests against 4.3 (or earlier) created after 5.0 went final will be dealt with as discussed above in regards to asking that the reporter verify the issue against 5.0.

These are great opportunities to take on a champion role.