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