aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: Release / verisoning requirements (was Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/)
Date Mon, 07 Feb 2011 14:54:59 GMT

>>> 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 :-)


View raw message