Sorry you hadn't gotten a response.
The thing to remember about organizing your changesets is that in
the end they get flattened into a list and ran from top to button, and
order can matter. Just like it is usually best to add changeSets to
the end of a changelog, you normally only want to be adding to the
"last" nested changelog in the flattened list.
It can work to have independent changelogs by feature or by
component, but only if the database objects in those files are
completely independent. If there is overlap and references between
them, it will cause problems down the road.
Normally my suggestion is to break up changelogs by release. Have a
1.1.xml, 1.2.xml, 1.3.xml file etc. That generally gives manageable
sized files and automatically has you working on the end of the
flattened list. If you end up going back to a fixpack on an earlier
version, adding to the earlier changelog usually works just fine
because since the change won't depend on anything in later versions.
Nathan