On 8/23/10 1:35 PM, David Jencks wrote: > 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. I was under the impression that the JMX spec implementation was stable. Is this not the case?
Justin > > 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 >>> >> >
