I'd like to commit this if nobody objects, its trivial and will reduce confusion.
I would have (objected), only it all happened so fast while I was asleep .
I called the constant like that because I didn't like the other constant names (and don't like the new one either). The problem is that when it comes to remove support for a certain format, it is very hard to understand from the constant name what index format it represents.
Instead, I chose a meaningful constant name for the developer, with a documentation that explains what has changed. When we're on 5.0 and need to remove support for 3.x, it will be very easy to delete all the places in the code which reference FORMAT_3_1, rather than go ask Mike what version FORMAT_SEGMENT_RECORDS_VERSION relates to .
Also, in LUCENE-2921 I plan to get rid of all those ridiculous constant names and track the index version at the segment level only. It will be easier, IMO, to have an easy to understand constant name when it comes to supporting an older index (or remove support for). Perhaps it's only me, but when I read those format constant names, I only did that when removing support for older indexes. Other than that, they are not very interesting ...
What Hoss reported about CheckIndex is the real problem we should handle here. SegmentInfo prints in its toString the code version which created it, which is better than seeing -9 IMO, and that should be "3.1" or "3.2". If it's a 3.2.0 newly created index, you shouldn't see "3.1" reported from SegmentInfos.toString. Perhaps CheckIndex needs to be fixed to refer to Constants.LUCENE_MAIN_VERSION instead?
Robert, shall we reopen the issue to discuss?