Hi, On Thu, Jun 26, 2008 at 12:25 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > I do not envision weekly releases of single components. But there may well > be one or two releases (or more) per month, yes. We also have this over at > Felix and it works quite well.
OK. I'm just wondering how it looks to a potential end user. Looking at the Felix download and news pages, it's quite difficult to determine whether an end user needs to care about all that. A release is not just an artifact pushed to the Maven repository, but also related stuff like release notes and relevant documentation updates. Each release should come at least with enough information to tell a user whether they should upgrade and what the effects will be if they do. > I would only consider merging if it would make sense on a code-wise basis. > Merging to "simplify" release management is IMHO wrong and bad. How about merging to simplify end user experience? Unless we can somehow automate upgrades (wouldn't it be cool if bundles and all the dependencies were automatically downloaded from the Maven repository... :-), our users could well end up manually managing a complex dependency tree. At least we should document the component dependencies somewhere. > In the end, we should make everything a bundle. This enables all use cases, > import and embedding. Because, remember: A bundle basically is just a JAR > with special manifest headers. The bigger difference is how they are presented to the user in a running system. For example, on the web console, does it make sense that for example commons-collections can be individually removed or upgraded? How aware the end user should be of all the inter-component dependencies? IMHO, the fewer dependencies the user needs to worry about the better. For example, say I have a component that uses some fancy new Map implementation in a recent commons-collections release. When a user deploys my component, it would be nice if she didn't need to also worry about the commons-collections version. IMHO the same reasoning applies also to things like commons/json. BR, Jukka Zitting
