Those are the requirements I would consider important for a release. If not all those requirements are compatible, we need to agree on removing some requirements or weaken them I suppose. I just want everyone to understand what the development and release processes will look like when we have defined our solution. If we don't agree with the outcome, we'll have to go back to this requirement list and modify those or find a different technical solution.
I think I'd like everyone to think about is read the semantic versioning whitepaper and give it some thoughts. What problem does it try to solve? It in fact remembers me of some discussion I had a few months / years ago about a bundle importing / exporting its own packages. Someone quote Peter Kriens that such a behavior was indeed a good practice. When I wanted to have bundles only exporting the packages, there were some push back (the discussion was actually on [email protected] about a patch I submitted). Those guys were not really OSGi experts, so the only thing they could do was to blindly follow so called best practices, hereby forgetting about the context of those best practices. Importing/exporting a package is about increasing substituability of packages in the OSGi framework, so it only makes sense for a *real* API. A library such as commons-io or lots of projects which are not developed *for* OSGi (i.e. they are mostly developed as libraries) can't use this policy as this would plainly break the whole system if you try to deploy multiple versions. Now, back to semantic versioning. *I* think the overall goal of semantic versioning is to make sure the users of our packages know what to expect when they import a package with a given range. I.e. if they just use a package, something like [1.0,2.0) should work. If they implement some of our interfaces, they should use a stricter package such as [1.1, 1.2). The rules are just here to provide guidelines that should be followed to ensure that. That said, the part I tend to slightly disagree with is that we should *only* bump the micro version if there has been a change, or that we should only bump the minor version if there has been an imcompatible change from an implementer point of view (and here, what does this mean for packages that are not pure API? I guess one conclusion is that the whitepaper does not really talk about those, just about pure api packages), or that we would not be allowed to change the major version if there is no incompatible change. And the reason why I disagree with that is that it does not help solving the compatiblity problem, the goal here is to reduce class-space fragmentation. Class-space fragmentation however has other solutions I think, and applications / subsystems are clearly a way to solve that problem. I'd rather have a way to have bug fix release and raise the level of fragmentation .... But if we decide to go to a strict application of the semantic versioning, I'd like everyone to understand that we won't be able to do bug fix releases. Just my 2 cents. On Mon, Feb 7, 2011 at 16:30, zoe slattery <[email protected]> wrote: > > Hi >> >> Well, given I still haven't understood how we're going to release >> things (per bundle or per component, as it seems a single whole >> release hasn't really received much support), I think our current >> layout conflict with #6 and we still haven't found a clear way to >> align #1 with #7 afaik. > > Yep - but if we accept your requirements we have to find a way to align #1 > with #7, don't we? > Finding a way to meet #6 is hard. I will go on experimenting and come up > with a concrete proposal for discussion later this week I hope. > I will collect up your list and put it on the Website somewhere so that it > doesn't get lost. > > By the way - does Sling meet all of these requirements? Because one option > (if someone is doing it right already) is simply to copy their process. > > > Zoe > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
