In order to experiment with variations in:
-module versions
-bundle versions
-package versions
the best thing to do is to branch and play around in a branch, so I'll
do that now and and summarise my conclusions (if any :-) )
on the list.
Zoe
On 1 February 2011 17:37, zoe slattery<[email protected]> wrote:
On 01/02/2011 17:03, Guillaume Nodet wrote:
As I said in my previous mail, one possibility would be to split the
release cycle and artifact versioning scheme from the osgi package
versioning scheme.
Which we already do to some degree when we release blueprint-bundle
which contain the blueprint-api in version 1.0 and the implementation
in version 0.3.
I think this is worth looking into.
Honestly, given the hassle of releasing things, I think a single trunk
+ single release cycle is the easiest way to go. I think if we have
a simple release process, we could release things more often and maybe
maintain branches. I don't really see any problem in having
blueprint-cm-0.4.0 being the same as blueprint-cm-0.4.1. But if it
takes 2 days to one person to do a release, less people will volunteer
to do those, which is imho worse, as we won't deliver fixes to our
users.
The release process as it stands is actually very simple - and - though I
should probably not say it myself - it is well documented.
FWIW I think it's good :-)
It took me a little time to do 0.3 but I had/chose to make fixes to a lot of
poms.
if we'd had smaller more frequent releases it would have been done
bit-by-bit and not taken a lot of time to do all in one go.
I worry a lot about making the development process more complex. The reason
that I was fixing poms for 0.3 is that one or two people didn't
understand the pom construction, also there were a few licences to fix.
Without these issues (which are completely avoidable
by putting comments in the poms and running rat in the build) it would
really be quite fast to release the whole of Aries.
Take application 0.2.1 as an example - that happened very quickly.
What takes the time is the 72 hours for the vote but that's not 72
hours of working time, just elapsed time. Also, the need for 3 PMC
members to vote (and hence have checked the release) - well if it's
small it'll be quicker to check.
Making the development process complex will make it harder to remember - and
will likely make releasing harder because people won't remember
the development process and the release manager will then have to fix it.
Also, if it's so hard for us to think of what the process should be, isn't
that an indication that we are heading for something too complex?
Zoe
On Tue, Feb 1, 2011 at 16:22, Jeremy Hughes<[email protected]> wrote:
On 1 February 2011 14:54, Guillaume Nodet<[email protected]> wrote:
This is very different from what we have I think, as gogo's root pom
isn't used at all.
Releasing gogo involves releasing each of the maven subproject
independantly afaik.
The main difference is that all felix releases consists of a *single*
bundle. If we go this way, that would mean that releasing blueprint
only would require 13 releases. Some of those just contain tests, so
that does not make sense to me. From an usability point of view, I
would definitely not go that way. I'd personaly rather go in the
opposite direction and use a single reactor / release for all
components.
Another consideration is that I think we should tie the release cycle
with the svn layout, i.e. if we want to keep each component with a
separate lifecycle, we should have multiple trunks. That's way
cleaner imho (and much more git friendly btw).
Lets discuss the multiple trunks idea a bit ... are you suggesting
something like:
aries/application/branches
aries/application/tags
aries/application/trunk
aries/blueprint/branches
aries/blueprint/tags
aries/blueprint/trunk
etc
We'd still be left with the multiproject issue - release blueprint
0.3.1 for a single fix and all the blueprint bundles are released
whether they contain fixes or not. If each child of
aries/blueprint/trunk was only a single bundle (they are today, but
other top level modules like application would need some changes to
fit with this) ... then we could release each of them independently.
But ... every time we release a bundle in blueprint we need to release
the 'uber' bundle - built from blueprint/blueprint-bundle. So, for
example, we would get to a situation where we release a fix to
blueprint-core @ 0.3.1 (and hence uber blueprint 0.3.1). Then
blueprint-cm needs a fix release - it's next micro number would be
0.3.1 (we'd have to release uber blueprint @ 0.3.2).
If blueprint-api then needs to release some additions to an interface,
then according to semantic versioning rules, it has broken
implementors of the interface, so its minor number goes up (to 0.4)
and of course blueprint-core implementing that would need to go up to
0.4, and the uber blueprint bundle would go up to 0.4 too - but other
blueprint bundles wouldn't get released and hence stay at 0.3.
This is a fairly complex process that we'd need to be careful to get
right.
On Tue, Feb 1, 2011 at 15:25, zoe slattery<[email protected]>
wrote:
Hi Felix
I had a look at felix to see if I could work out how you do the
independent
releases. I didn't look through absolutely everything but
I only found two modules that had sub-modules (gogo and http). Of those
two
it looks as though the pom structure in gogo might be similar
to what we need in Aries. Is this a model you would recommend? Or is
there
something closer?
Zoe
Hi,
Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
Wouldn't that imply that each bundle has its own lifecycle ?
I think a while ago we agreed on having one release per "component",
i.e. blueprint (which includes api + core + cm + ...).
I'm not sure how well this would go if we have blueprint-core
0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
I bet you won't release blueprint-api as version 0.4.0 if it is the
same
as 0.3.0, right ?
Regards
Felix
From a users point of view, it certainly does not help because all
the
maven transitive dependencies are kinda screwed.
On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<[email protected]>
wrote:
Hi,
Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
(c) Where an Aries module depends on other Aries modules, it will
depend
on the released versions of the other modules _until_ it requires
a
change in the module that it depends on, at which stage it will
switch
to a dependency on the development version.
So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce
0.3,
proxy
0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT
needs
to
pick up a change in proxy the blueprint top level pom will need
to be
modified to point to proxy 0.4-SNAPSHOT.
I would assume this means "depends on modified API" and does not
mean
"depends on some bug fixed in the implementation", right ?
If you're referring to the semantic meaning attached to moving from
0.3 to 0.4 then I think that would be taking this discussion in a
different direction. But that is a good point. Before getting into
a
semantic versioning discussion, I think the intent of this was to
so
if there are broken tests in 0.4-SNAPSHOT of a module which are
fixed
by pulling in 0.4-SNAPSHOT of its dependency then its dependency
should be updated.
No, this is not about semantic versioning (yet).
This is about the following: Consider bundle X depends on the API
org.apache.aries.y.api of bundle Y. Now some implementation of this
API
in package org.apache.aries.y.impl of bundle Y has a bug which must
be
fixed. In this case the dependency of bundle X on Y should not be
changed.
Regards
Felix
Regards
Felix
This will lead us towards being able to release by module but it
implies
a change in development practice. I will make the pom changes
locally
and test them but I'd like to check that release-by-module is
still
the
goal and that you all think this is a reasonable way to be able
to
achieve it.
Zoė
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
