My understanding of our current situation is that we have set up the "subprojects" to support and encourage releasing them on separate schedules but that both the 0.1-incubating and 0.2-incubating releases have happened to support external users rather than because a particular module is in a particularly stable state. I expect that once at least one module is in a stable state it will proceed on an independent release schedule.
The main change felix recommends from the procedure in my mind I think we're following :-) is to use the minimal working version of dependencies rather than the latest. I actually think with appropriate bnd version templates it shouldn't make any difference to what ends up in the import-package header but I don't think the correct bits of bnd are available in the maven-bundle-plugin yet. thanks david jencks On Aug 23, 2010, at 9:19 AM, Felix Meschberger wrote: > Hi, > > On 23.08.2010 17:51, Timothy Ward wrote: >> >> Hi all, >> >> I also agree that we need a process by which modules can be released >> independently from one another. I do, however, think that this should not >> occur until we are ready to declare a set of modules as a 1.0 release. There >> are several common utilities and inter-module dependencies that will be very >> difficult to formalize until release 1.0, particularly because at the moment >> we do not strictly apply versioning rules to our packages. > > Don't wait too long. Target the ultimate goal and work towards it. You > will, as my experience from Sling tells, refactor package and reorganize > bundles. > > No problems, do it, but keep the goal in mind. > > Regards > Felix > >> >> Regards, >> >> Tim >> >> ---------------------------------------- >>> Date: Mon, 23 Aug 2010 11:08:15 -0400 >>> From: [email protected] >>> To: [email protected] >>> Subject: Re: release process questions around versions >>> >>> >>> Thanks Zoe and Felix. >>> >>> I too agree that Felix raises a number of very good points and I also >>> believe that we should be striving to release individual modules - it's >>> only right and consistent to do so. It's just that our process doesn't >>> currently support this well and things like samples get a little messy. >>> Thank you too Felix for the pointers to the Sling links - we need to >>> look into this more carefully to learn from your experience. >>> >>> So, I think we have two slightly conflicting goals that we are trying to >>> achieve. >>> >>> 1) We'd like to release individual modules on individual schedules as >>> necessary. We need to update our process to accommodate this goal. >>> >>> 2) While independent, our modules can also work together in concert to >>> enable enterprise OSGi applications. As such we would like to >>> demonstrate them working together and make it easy for a user to do the >>> same. >>> >>> My original note was primarily to highlight the problem and start a >>> discussion. I also did a little "thinking out loud" and perhaps lapsed >>> into a bit of monolithic thinking near the end - longing for a more >>> simple solution. That probably isn't the best approach. We should be >>> able to do something to accomplish both goals - perhaps following >>> Sling's lead. >>> >>> Thanks, >>> Joe >>> >>> >>> On 8/23/10 10:11 AM, zoe slattery wrote: >>>> Felix - thanks. You make some good points. Our current problem is that >>>> our development and release process isn't (unlike Felix) a mature >>>> process and currently is not designed to facilitate releasing by module. >>>> >>>> If we go this way we need we need to work through some changes and >>>> everyone who contributes need to understand them :-) >>>> >>>> Thanks again, Zoë >>>> >>>>> Hi, >>>>> >>>>> Sorry to bother from the outside: But, isn't this a project build OSGi >>>>> bundles ? >>>>> >>>>> So I suggest you stop thinking in traditional, monolithic application >>>>> terms, where everything always is built and glued together at the same >>>>> time. >>>>> >>>>> In the OSGi world this is fundamentally different: Parts of the >>>>> application are built at build-time and glued together at deployment >>>>> time. >>>>> >>>>> This is a big plus to your users in that they don't have to always >>>>> update the complete application just in case of a small fix. >>>>> >>>>> It is adding more to the developer's task, but rightly so: You, the >>>>> developer, are fully in charge to ensure compatibility of your module. >>>>> This is what "API" is all about. >>>>> >>>>> Try it, and you will start to enjoy it; really ! >>>>> >>>>> On 22.08.2010 11:03, zoe slattery wrote: >>>>>> I agree that this needs some rethinking in the light of experience. >>>>>>> We're in the process of releasing our second set of modules. This >>>>>>> sheds new light on the module version and release process discussions >>>>>>> we had earlier. It also raises some questions about how we ideally >>>>>>> want to handle certain scenarios now that we are forced to deal with >>>>>>> more than one release. >>>>>>> >>>>>>> 1) Should the first release of a new module use the prevailing version >>>>>>> at the time or do we intend to always start with the logical "1" of a >>>>>>> first release? For quiesce we used the prevailing version - >>>>>>> 0.2-incubating. >>>>>> If we had released quiesce at 0.1-incubating I guess that it should have >>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right there >>>>>> there needs to be some guidance for developers because I don't think >>>>>> it's obvious. >>>>>> >>>>>> At the same time as introducing quiesce, changes were made to jpa - >>>>>> which now depends on quiesce. So, if we were releasing jpa at >>>>>> 0.2-incubating it would need to depend on a release of quiesce created >>>>>> at the same time and called 0.1-incubating. >>>>> Version numbers of modules identify the development history of a single >>>>> module. Lets keep it that simple. Don't overlay this semantic with the >>>>> semantic of the version of the complete application. This ain't gonna >>>>> work in the not so far future. See >>>>> http://wiki.eclipse.org/index.php/Version_Numbering. >>>>> >>>>>>> 2) How will we make multiple component versions available in the >>>>>>> future for download? If we always release all modules (as we did in >>>>>>> our 0.1 and 0.2 releases) then it's simple - we can create a download >>>>>>> page for each release and we can create documentation per release. >>>>>>> However, if we start to release the modules individually things get a >>>>>>> bit more complicated. One possibility is to move from one common >>>>>>> download page to a download page per module. >>>>>> That would be OK if they were truly independent. I've drawn here the >>>>>> dependencies that I observed when I was testing the 0.2-snapshot >>>>>> release. >>>>>> https://cwiki.apache.org/confluence/display/ARIES/ModuleDependencies. >>>>>> The relationships indicated in the picture just show what happened when >>>>>> I tried to build something - so for example, the jpa build failed with >>>>>> missing dependencies until I had 'mvn install'd quiesce, util, >>>>>> testsupport and parent. >>>>> Just keep in mind, that for deployment, your jpa 0.2-incubator module >>>>> version will depend on some API currently provided by some version of >>>>> the quiesce module. The JPA does not care, who actually provides the >>>>> API, as long as its there. >>>>> >>>>> Thus built-time and deployment-time dependencies are not the same in the >>>>> OSGi world. >>>>> >>>>>>> 3) Are there other benefits in keeping the module versions consistent >>>>>>> and concurrently releasing all modules rather than individual modules >>>>>>> that we haven't really considered? I'm thinking about things like >>>>>>> documentation, test validation, and samples. >>>>>> The main point of the blog sample is to bring together a number of the >>>>>> modules and show them working in one application, I think this might be >>>>>> true of ariestrader too. Trying to think about how to maintain either of >>>>>> these samples to work with a set of independently released modules is >>>>>> making my head hurt. >>>>>>> Thinking more about #3 - It seems it might be very difficult to >>>>>>> maintain our documentation and samples once the module versions begin >>>>>>> to diverge. Changes to one module might force us to want to release >>>>>>> or update some other module, ... such as the case with (and perhaps >>>>>>> only with) samples. In fact, samples might be impacted by the release >>>>>>> of each module if we want to try to keep them as current as possible. >>>>>>> This might result in a proliferation of sample releases. Moreover, >>>>>>> the combination of modules/versions we use in our sample releases >>>>>>> might not demonstrate or validate a common set of modules/versions >>>>>>> that a user might choose. Yes, all valid versions based upon >>>>>>> dependencies *should* work fine together ... but that assumes nobody >>>>>>> makes mistakes. There is a certain comfort (from a user perspective) >>>>>>> in knowing that a particular set of modules has been tested together >>>>>>> in some fashion which can at least be partially demonstrated in our >>>>>>> samples. >>>>>> I agree. >>>>>>> I understand why we started down the path of individual components and >>>>>>> I definitely agree that it has value ... I'm just rethinking the >>>>>>> decision now that we are doing our second release and have to deal >>>>>>> with multiple versions for the first time. The second release begins >>>>>>> to set the precedent for how we deal with some of these things. The >>>>>>> fact that we basically released everything again with a consistent >>>>>>> version makes me wonder if that should be our standard process instead >>>>>>> of individual component versions. >>>>>> There are advantages in being able to release a module separately. For >>>>>> example if we find something we need to fix in one module, and it's a >>>>>> self contained fix, we could create a new release of that module quite >>>>>> quickly. On the other hand, the slow part of the release process (72 >>>>>> hours for a vote, then another 72 for the incubator PMC?) remains the >>>>>> same. >>>>> Yeah, sure that may seem a problem (but there is a reason for this, >>>>> though). But this should influence the decision of whether to do >>>>> single-module releases or not. >>>>> >>>>>> On balance I'm in favour of a single release at a set level - however - >>>>>> if we can find an absolutely crystal clear way to document a >>>>>> release-by-module system I think it could work; I'm worried by the >>>>>> complexity it would lead to in documentation and samples. >>>>> I fear you worry on the wrong end of the story. Worry about the >>>>> interfaces between your modules and look at what the modules really >>>>> need. Your modules depend on services and API; they don't depend on >>>>> other modules. >>>>> >>>>> At one point in time you will realize that you have some modules which >>>>> are mostly stable and some modules which are under heavy development. So >>>>> you will release the moving parts (modules under development) and not >>>>> release the static parts. >>>>> >>>>> Doing module releases also enables you to "release early, release often". >>>>> >>>>> Try it, enjoy it. For me this is what OSGi is mostly and almost all >>>>> about. >>>>> >>>>> Regards >>>>> Felix >>>>> >>>>>> Zoë >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Joe >> >
