On Thu, Jun 26, 2008 at 9:32 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> ...As far as I've understood, the plan going forward is to have separate > release cycles for all Sling components.... Here's the way I see it, and I think this matches in a large part what's been discussed in this thread. Any Sling bundle can be released independently, when the committers agree that that makes sense. Some bundles belong together, and when releasing one it makes sense to release all others from the same group. I guess these groups will be invented as we go, and we can use component names in JIRA to keep track of what's what. By default, Sling users are expected to use the "big" Sling releases, for example what's under [1] for the current release, which is also available as app and webapp binaries. Mixing and matching bundles released in between "big" releases is ok if people assume the risks that go with that. Our integration tests help checking the compatibility of bundles, but people are expected to add their own tests (or better, contribute them to the project) to verify this. We could use the word "global release" for the big releases, and "bundles release" when releasing individual or groups of bundles. I think there's only one thing missing for this to really work: we should have a way of including automated tests in bundles, that can be run in the actual Sling instance where the bundle is installed. Having a list of testable bundles under /system/self-test, with a user interface to run the tests, would make it much easier to test various combinations of bundles. Shouldn't be too hard to implement if we consider a test suite as an OSGi service. -Bertrand [1] http://svn.apache.org/repos/asf/incubator/sling/tags/sling-3-incubator-source-release/
