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.
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
