Hi
Yes, each bundle has its own change log because each bundle release has its own Version identifier in JIRA. But we collect similar bundles into bigger compoinents. For example all scripting related bundles (api, core, scripting language support) are under the same "Scripting" component.
Sling is an interesting model. The essential difference between what you do and what we currently do in Aries is that our bundles are grouped in modules and that the module is the thing that we release. If we stay with this we either need to accept that we may well release exactly the same thing twice (or more) under different names or find a way to release the bundles that have changed when we release the module. To do this, after a release (say 0.3), the module version changes to 0.4-SNAPSHOT but it's internal dependencies (sub modules) should all be on released artifacts. The sub-modules would need to be commented out of the module's pom. When a change is required in the sub-module it's version has to change to A.B.C-SNAPSHOT and the it has to be listed as a module in the parent modules pom again.
This is rather ugly, but it does work - see this pom.xml for quiecse https://svn.apache.org/repos/asf/aries/branches/experimental-release-by-module/quiesce/pom.xml. This means that we'd never increase a bundle version artificially and when we came to release (say) quiesce we would not re-release the same code with a different name. The release process still gives you all the source for the whole quiesce module - which I suppose is OK.
