aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: release process questions around versions
Date Mon, 23 Aug 2010 14:11:59 GMT
  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
>>> 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.
>> 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ë

View raw message