The idea is to add support for all types that were supported in Search 5.
You can find the types supported in Search 5 by having a look at implementations of org.hibernate.search.bridge.spi.BridgeProvider. This should essentially include all primary types, java.util.Date, java.util.Calendar, the java.time types, the numeric types (Short, Double, Float, ...), BigDecimal and BigInteger, and maybe more.
Only the boxed versions of types (Integer, not int) actually require code in the backend to support them, the others should be supported automatically thanks to existing code in the mapper.
The code changed a bit since HSEARCH-3265, but on a higher level the list of tasks will be fairly similar.
For each type, we need to:
Implement the backend support:
Add a asMyType() method in the field type definition API, and the appropriate implementation in each backend (Lucene + ES). Please look at existing implementations for similar types first, you may be able to reuse code. In particular in the Lucene backend, there is a common pattern for all numeric types.
Update the implementations of the as(Class<?>) method in the same interface to support the new type
Add integration tests to the backend TCK. This mainly means implementing a org.hibernate.search.integrationtest.backend.tck.testsupport.types.FieldTypeDescriptor and referencing your implementation from org.hibernate.search.integrationtest.backend.tck.testsupport.types.FieldTypeDescriptor#getAll. See org.hibernate.search.integrationtest.backend.tck.testsupport.types.LongFieldTypeDescriptor for an example. After you implemented that, run org.hibernate.search.integrationtest.backend.tck.search.predicate.MatchSearchPredicateIT#match and check that your type appears in the list of tests.
Implement the mapper support
Register a default value bridge for the type in org.hibernate.search.mapper.pojo.bridge.impl.BridgeResolver#BridgeResolver. Generally a PassThroughValueBridge should be enough, but in some cases you may want to add a specific implementation (java.util.Calendar in particular, see below).
Where that makes sense (= the type could reasonably be used as an entity ID), register a default identifier bridge for the type in org.hibernate.search.mapper.pojo.bridge.impl.BridgeResolver#BridgeResolver.
Add integration tests to the pojo mapper ITs. This mainly means implementing a org.hibernate.search.integrationtest.mapper.pojo.testsupport.types.PropertyTypeDescriptor and referencing your implementation from org.hibernate.search.integrationtest.mapper.pojo.testsupport.types.PropertyTypeDescriptor#getAll. See org.hibernate.search.integrationtest.mapper.pojo.testsupport.types.BoxedLongPropertyTypeDescriptor for an example. After you implemented that, run org.hibernate.search.integrationtest.mapper.pojo.mapping.definition.FieldDefaultBridgeIT and check that your type appears in the list of tests.
Note that for boxed/primitive types (Short/short) you need an implementation for both the boxed type and the primitive type.
Note there are particular cases: Calendar in particular doesn't need to be implemented in the backend; converting it to a ZonedDateTime should be enough. So you will only need to implement a bridge in the mapper similar to org.hibernate.search.mapper.pojo.bridge.builtin.impl.DefaultJavaUtilDateValueBridge, reference it from the bridge resolver and add mapper tests: nothing to do on the backend side.
As to the commits, I would recommend to not be more precise than, for each type one commit for the backend impls (both ES + Lucene), one for the backend tests, one for the mapper impl, one for the mapper tests. And I think you can safely squash that into just two commits, one for the backends and one for the mapper.