Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of zoe.slattery@gmail.com
 designates 209.85.215.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=n9a0fNwbnSOXlVoBMN/nAs6EAeZE930dz1xqdToRrK+4ZRx9jabwVejZkOjlOkttu9
         e9ONDRO0jWz7khOilEqk1lhEtvQmbJHsftYdYrUknpCdQi0e64PzMwA4HoSKMxPwhFnM
         GxKO9w+G2w3KL3NLuMkX2yOXAwmk1aQ0Q8Ejo=
Message-ID: <4C73C26B.90201@gmail.com>
Date: Tue, 24 Aug 2010 14:00:27 +0100
From: zoe slattery <zoe.slattery@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: aries-dev@incubator.apache.org
Subject: Re: release process questions around versions
References: <4C6EDF38.4010804@gmail.com> <4C70E7F2.8010006@gmail.com>
 <4C71093C.2010003@gmail.com>
 <4C7281AF.7000807@gmail.com>,<4C728EDF.4090007@gmail.com>
 <BLU128-W4F50BAA081EDFC927302BDF820@phx.gbl>
In-Reply-To: <BLU128-W4F50BAA081EDFC927302BDF820@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

  On 23/08/2010 16: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.
Yes - I think that's the short summary of where we are.

I spent some time thinking about what would have to change in our 
development process when we release by module. There are problems that I 
don't know how to solve, but maybe someone else does. Here is one of them:

It is really important that people can build our released source code 
without having to modify the poms. Consider this example - at the moment 
the candidate release pom.xml in the JPA has dependencies which look 
like this:

<dependency>
<groupId>org.apache.aries</groupId>
<artifactId>org.apache.aries.util</artifactId>
<version>0.2-incubating</version>
</dependency>

So, we would need to have released a 0.2-incubating level of 
org.apache.aries.util before (or at the same time as) the 0.2 incubating 
level of blueprint.

I think this means that we need to change all the projects in trunk to 
depend on released versions of other projects. So a 
0.3-incubating-SNAPSHOT version of JPA in trunk would have this in it's 
pom.xml

<dependency>
<groupId>org.apache.aries</groupId>
<artifactId>org.apache.aries.util</artifactId>
<version>0.2-incubating</version>
</dependency>

This means that we will not be testing the development versions of other 
projects - which is fine as long as they don't change.

What would happen in this scenario when a util developer introduced an 
API breaking change in trunk? Surely the development (trunk) version of 
JPA should be modified to depend on the new version of util which is 
under development? How would the JPA maintainer know this had to happen? 
Is there any tooling to automate it?

I think we need answers to these, and some similar more involved 
questions about samples and docs, before we can switch to a module based 
release.

Zoe

> Regards,
>
> Tim
>
> ----------------------------------------
>> Date: Mon, 23 Aug 2010 11:08:15 -0400
>> From: joebohn@gmail.com
>> To: aries-dev@incubator.apache.org
>> 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
>