On 04/02/2011 12:33, Guillaume Nodet wrote:
Afaik, the maven release plugin can actually release several maven
projects at the same time each one having its own release number.
Meaning when you release a project consisting of several maven
subprojects, each one can have its own release version (whether or not
that's desirable is a completely different problem).
Yes, I think it can.
On the osgi versioning problem, I'm not sure we have to assume that
the version number of the package is the same as the one for the
bundle, so the fact you need to specify a range isn't related to the
release process.
No - it's part of the development process. I think it _is_ assumed by
what is in our default parent pom at the moment.
The maven bundle plugin can automatically generate a
range based on the information it finds, so here again, it's related
to the package versioning, not the bundle versioning. Please remember
that the semantic associated to the version in OSGi is at the package
level, not the bundle level.
Understood.
Last, I'm not sure we're going into the right direction. I think
those decisions should not be bound to technical considerations so
early in the process.
I don't think we are going in any particular direction at the moment -
or at least I'm not. The reason for the experimental branch was to
try and understand more about what we would have to do to get semantic
versioning correct for both bundles and packages.
I'm quite sure we have a lot of freedom in choosing how we want to
version things and release them.
Maybe we should start by stating by agreeing on what we'd like first.
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
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)
Z
On Fri, Feb 4, 2011 at 13:18, zoe slattery<[email protected]> wrote:
On 03/02/2011 22:28, Guillaume Nodet wrote:
What kind of experiments do you have in mind ?
Probably this is more to do with my understanding (or lack of) of the way in
which the current maven
build specifies versions and how the release process deals with them.
I'm not sure to actually understand how the release process will be
different if we release everyting in one go, component by component,
or bundle by bundle. At the end, it always comes down to the same
steps: updating pom dependencies, mvn release:prepare release:perform,
updating jira, vote, updating the web site, annoucement.
The obvious different will be at which level you run the command from,
but apart from that, I kinda fail to see what kind of impact it would
have.
The aim is to keep the release process the same, as you say. To take a
specific example, I was looking at the quiesce module, the sort of thing
that the pom.xml would need to indicate is:
1) Quiesce module depends on released versions of parent, testsupport, util
(this is easy)
2) Quiesce module depends on a released version of the quiesce api (one of
the agregator's sub-modules) but development versions of the implementation
sub-modules.
At the moment to make step 2 work it's necessary to override the default
package imports for, say, the quiesce manager implementation and comment
out quiesce-api in the modules section. After that I get something which
builds and runs - the quiesce manager implementation bundle has the correct
package imports. I've checked in the quiesce pom (with debug in it). I'm not
quite sure what the release process will do with this, so I need to check.
Zoe
On Thu, Feb 3, 2011 at 16:11,<[email protected]> wrote:
Author: zoe
Date: Thu Feb 3 15:11:33 2011
New Revision: 1066827
URL: http://svn.apache.org/viewvc?rev=1066827&view=rev
Log:
recreating with 0.4 from trunk
Added:
aries/branches/experimental-release-by-module/
- copied from r1066825, aries/trunk/
