Hi, a couple of questions/comments... On 7 February 2011 15:51, Guillaume Nodet <[email protected]> wrote: > 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. >
What would the motivation be for bumping versions that imply greater incompatibility, which is what I think you're suggesting you'd like to do? If we do this, then this has a knock-on effect of imports. How does a consumer know what range to import? If they follow the OSGi Alliance best practice, then they'll have to change their imports more frequently than necessary and there'll be fewer opportunities to put together coherent sets of bundles and less opportunity to fix systems without having a knock-on effect on other bundles. We make the dependencies more brittle. > 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. > Semantic versioning helps maximmise sharing and flexibility of assembly. Sticking to this policy maximises the opportunities to create a consistent solution from a set of bundles. Applications and subsystems don't solve all the same problems. Granted, you can use them to partition up the classspace, but what if you actually want a consistent class-space across the bundles because they share types. Partitioning up the class-space won't solve that, only having flexible imports that maximise resolution opportunities will solve that. > 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 >
