You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Guillaume Nodet <gn...@gmail.com> on 2011/02/03 23:28:46 UTC
Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/
What kind of experiments do you have in mind ?
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.
On Thu, Feb 3, 2011 at 16:11, <zo...@apache.org> 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/
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/
Posted by Jeremy Hughes <hu...@apache.org>.
On 4 February 2011 13:11, zoe slattery <zo...@gmail.com> wrote:
> 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
I think it's more than this - Aries isn't just an OSGi project, it's
infrastructure to enable OSGi based applications. We need to
demonstrate how semantic versioning can be be achieved throughout the
lifecycle of a multi-bundle project, so that others can learn and
follow that.
> 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
By this I take it you mean a release of all the releasable code we
have in one go. I'd like to point out that we don't really have this
today - we just happen to do a release for each of the top level
modules and vote for them at the same time. I think this is: release
all the artifacts that have changes and hence need a release and at
the same time release a roll-up of all those new artifacts and all the
others that didn't need a release. By doing this roll-up release we'd
be making a statement about the level of testing that had been done
with that combination of released child artifacts.
> (b) Release by module - with the correctly versioned bundles of
> sub-modules
A bit like (a) but for a single module (that potentially contains
child modules / bundles itself)
> (c) To avoid having to do release by sub-module (eg not having to do 17
> separate release steps for blueprint)
Agreed.
>
> Z
>>
>> On Fri, Feb 4, 2011 at 13:18, zoe slattery<zo...@gmail.com> 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,<zo...@apache.org> 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/
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/
Posted by zoe slattery <zo...@gmail.com>.
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<zo...@gmail.com> 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,<zo...@apache.org> 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/
>>>>
>>>>
>>>
>>
>
>
Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/
Posted by Guillaume Nodet <gn...@gmail.com>.
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).
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. 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.
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'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.
On Fri, Feb 4, 2011 at 13:18, zoe slattery <zo...@gmail.com> 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,<zo...@apache.org> 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/
>>>
>>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/
Posted by zoe slattery <zo...@gmail.com>.
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,<zo...@apache.org> 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/
>>
>>
>
>