aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Release / verisoning requirements (was Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/)
Date Mon, 07 Feb 2011 15:00:18 GMT
On Mon, Feb 7, 2011 at 15:54, zoe slattery <> wrote:
>>>> Before we go in any particular direction we must agree, that's true. Is
>>>> it
>>>> possible to agree with these goals now:
>>>> 1) As an OSGi project we must demonstrate best practice in our use of
>>>> semantic versioning at bundle and package level
>>> Agreed, though I don't think there's much semantic implied at the bundle
>>> level.
>>>> 2) A build and release process which allows us to do
>>>>    (a) A release of everything in one go with associated samples which
>>>> are
>>>> therefore guaranteed to work together
>>>>    (b) Release by module - with the correctly versioned bundles of
>>>> sub-modules
>>>>    (c) To avoid having to do release by sub-module (eg not having to do
>>>> 17
>>>> separate release steps for blueprint)
>>> Well, those are side issues imho and I think they conflict with the
>>> requirements I propose below.
>>> I'd rather have the following requirements:
>>>  1. correct osgi semantic versioning
>>>  2. a release must have a buildable source distribution (that's
>>> really an asf requirement, as the source distribution *is* really the
>>> release from an asf pov)
>>>  3. a release should have some release notes listing the changes in
>>> that release
>>>  4. a release must be publicly announced
>>>  5. users should have an easy way to download the bundles needed for
>>> a given component (blueprint, etc...)
>>>  6. easy tagging / branching mechanism
>> I'd also like to add those requirements:
>>    7. a way to provide bug fix releases
>>    8. a way to ensure that a given component does not have conflicting
>> dependencies
>> #7 is really important in my opinion, even more than #5 and #6.  I
>> can't even imagine how I would tell my customers I can't even do a bug
>> fix release.
>> #8 is about mitigating the dependency hell so that we actaully have
>> the ability to deploy a component which does not require two
>> dependencies with an incompatible version (i.e. for aries blueprint
>> x.y  we don't end up with requiring both aries-utils 1.x and
>> aries-utils 2.x).  This requirement is definitely not a must-have, but
>> a nice to have, as it's really for ease of use and consumption of our
>> components.
>> I haven't heard any feedback so far, but I think starting from what we
>> want is a better idea than investigating a technical solution now.  At
>> least discussing those requirements may end up to doing some
>> compromise over others if they are somewhat incompatible (i..e we
>> don't find a technical solution to solve all those requirements).
> I didn't reply earlier because:
> (a) I'm not sure what in your requirements conflicts exactly with my
> original suggestions? In any case I'm quite happy to abandon my suggestions
> in favour of yours.
> (b) I'm still trying to understand how we satisfy requirement "1. Correct
> osgi semantic versioning"
> Requirement 2, 3, 4 are relatively easy to satisfy.
> Requirements 5, 6, 7 are tied up in the semantic versioning discussion and I
> believe that if we choose to implement semantic versioning there are at
> least some implications for the way in which we meet requirements 5, 6, and
> 7. Not sure about 8.
> So, as a list of requirements I don't think there is too much disagreement,
> although perhaps other people would like chip in with their views.
> As I said, the reason for experimenting is about how to satisfy requirement
> 1 with the others. I feel that it's rather poor form that we (as an OSGi
> project) don't meet requirement 1 at the moment :-)

Well, given I still haven't understood how we're going to release
things (per bundle or per component, as it seems a single whole
release hasn't really received much support), I think our current
layout conflict with #6 and we still haven't found a clear way to
align #1 with #7 afaik.

> Zoe

Guillaume Nodet
Open Source SOA

View raw message