The FIX fields and messages classes are auto-generated from FIX spec xml files. Each FIX spec version has a corresponding jar created with its respective classes. The message package names contain the fix version (e.g. quickfix.fix44 package), so that a specific target version's messages can be used.

However, all field packages from all versions are simply named quickfix.field, so they cannot be targeted individually by code that needs them.

Worse, when all of these versioned packages are merged together into a single 'all' messages jar, the field classes overwrite each other in the quickfix.field package, which becomes a mix of classes from all versions. Seeing that the fields of newer versions are not entirely backwards-compatible with earlier versions (e.g. some field values/constants are renamed or removed), this package becomes compliant neither with the new versions or the old versions, and breaks existing client code when a new version is added (e.g. 5.0sp1/sp2) even if said code is intended to work only with and older spec version.

Worse still, the quickfix.field package is bundled not only in the quickfix-all jar but also in the quickfix-core jar, so they are not easily decoupled for users who want to select a specific target version jar to be used explicitly, or maintain a stable build unaffected by newer spec releases.

All these versions should ideally be decoupled from each other (and from core) in such a way that they can coexist in an application that must support multiple versions, and still remain compliant with each one of them independently.

These changes require additional research and have backward-compaibility implications. Currently the combined quickfix.field pakcage has the 5.0 spec classes trump all others (i.e. its classes take precedence when there are duplicates), to remain compatible with the previous release (even though new sp1/sp2 fields are added to the package as well).