aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: release process questions around versions
Date Mon, 23 Aug 2010 17:35:37 GMT
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.

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:
>>> To:
>>> 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.
>>>>>>> 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
>>>>>>> more than one release.
>>>>>>> 1) Should the first release of a new module use the prevailing
>>>>>>> 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
>>>>>> been created in trunk as 0.1-incubating-SNAPSHOT? If this is right
>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>> dependencies that I observed when I was testing the 0.2-snapshot
>>>>>> release.
>>>>>> The relationships indicated in the picture just show what happened
>>>>>> I tried to build something - so for example, the jpa build failed
>>>>>> 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
>>>>> OSGi world.
>>>>>>> 3) Are there other benefits in keeping the module versions consistent
>>>>>>> and concurrently releasing all modules rather than individual
>>>>>>> that we haven't really considered? I'm thinking about things
>>>>>>> documentation, test validation, and samples.
>>>>>> The main point of the blog sample is to bring together a number of
>>>>>> modules and show them working in one application, I think this might
>>>>>> true of ariestrader too. Trying to think about how to maintain either
>>>>>> these samples to work with a set of independently released modules
>>>>>> making my head hurt.
>>>>>>> Thinking more about #3 - It seems it might be very difficult
>>>>>>> maintain our documentation and samples once the module versions
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> I definitely agree that it has value ... I'm just rethinking
>>>>>>> decision now that we are doing our second release and have to
>>>>>>> with multiple versions for the first time. The second release
>>>>>>> to set the precedent for how we deal with some of these things.
>>>>>>> fact that we basically released everything again with a consistent
>>>>>>> version makes me wonder if that should be our standard process
>>>>>>> of individual component versions.
>>>>>> There are advantages in being able to release a module separately.
>>>>>> example if we find something we need to fix in one module, and it's
>>>>>> self contained fix, we could create a new release of that module
>>>>>> quickly. On the other hand, the slow part of the release process
>>>>>> hours for a vote, then another 72 for the incubator PMC?) remains
>>>>>> 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.
>>>>> 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

View raw message