Hi Joe,
Nice to meet you. I appreciate the work you and your predecessors have done and would love to help out.
I agree with the idea of getting a Hamcrest 4.0 with a requirement for a more recent version of Java out sooner rather than later. That’s why I started the Hamcrest 4.0 Draft PR (#443). It’s based on a minimum Java 17 baseline.
I’ve been merging existing PRs into that branch, starting with the most recent and working my way backwards. I’ve gotten as far as #345. My plan was to just keep merging existing PRs into that draft PR until I heard from someone. :)
How would you like to proceed? I think #443 is in a state that we could release it if you don’t mind 4.0 containing both a new baseline and some new functionality. If you would prefer something a bit more incremental, I could create a PR for updating the baseline and then one or more separate PRs for the new functionality.
After getting a 4.0 out, then I think the priority is to clear the backlog of existing PRs and issues. My experience is that (just like any branch) the longer a PR sits, the harder it becomes to merge it. So clearing PRs (by reviewing them, then merging or rejecting them) should be a priority. Also, it’s not really fair to ask a someone who submitted a PR years ago to perform that merging work. It’s no problem to request changes from a recently submitted PR but (IMO at least) it’s a bit cheeky to ignore a PR for several years and then request changes.
All this means that merging the existing PRs is probably going to take quite a bit of time, but I am willing to do it.
I am happy to continue reviewing and merging existing PRs until the backlog is cleared out. The only proviso is that I’m probably going to be reviewing from a technical perspective (i.e. is the provided code technically sound and can we still merge it without an overly burdensome amount of effort). I don’t know if I feel qualified to decide if the use case being addressed is too niche to warrant being covered in the core matchers. I will mainly be assuming that the existing PRs have merit from a functional perspective unless you tell me otherwise.
I will probably take the opportunity to tweak the incoming code to leverage newer language constructs and newer JDK APIs when possible.
Does that sound like a reasonable plan? How would you like to proceed on #443? I realize that it is a big PR which might make it difficult to review. Let me know. It really just consists of the work to move to Java 17 followed by the merging of existing PRs (starting with my most recent ones) and working backwards to #345.
I am thinking the following things need to happen if you’re OK with releasing #443 as Hamcrest 4.0:
1) I need to update the release notes document I created with info about the last PR I merged into that branch.
2) I need to close the draft PR to make it a final PR.
3) You should probably review it and if you’re happy with it, then merge it.
4) Create a 4.0 release.
I am probably missing some steps. You’ve been through this before and I haven’t. :)
Regards,
Rob