You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <jp...@gmail.com> on 2014/06/30 22:51:00 UTC
Top down build of trunk failing during release process (was: Re:
[VOTE] Release Apache Aries Parent 2.0.0)
After the release candidate artifacts are posted, module poms have their
version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are being
released at the same time were depending on 2.0.0-SNAPSHOT and moved to
depend on 2.0.0 as part of their own release process. Which is fine for
reviewing the release artifacts of all those modules together. However, the
part of the release process that bumps a module's version in trunk
subsequent to the tagging, doesn't bump the dependency versions. They
shouldn't: a) there's no reason to depend on snapshot b) it doesn't know
the module it depends on is being released at the same time and therefore
isn't available in a repository.
Our process for releasing modules together that have dependencies between
them, is causing the trunk build to be broken while the release vote is
ongoing. I'm not sure what other multi-module projects do and why we're
different, but surely they don't all suffer from this.
Any ideas?
On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> I'm new here and this may be obvious to others. While we are in release
> mode, is it expected that trunk will no longer build due to references to
> the unreleased 2.0.0 parent pom? Is there a good process to follow in
> order to be able to build everything locally while doing other work that is
> not in the middle of being released?
>
> Tom
>
>
>
> [image: Inactive hide details for Guillaume Nodet ---06/30/2014 01:10:56
> PM---This is the first release of a set. It contains the paren]Guillaume
> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set. It
> contains the parent pom in version 2.0.0
>
> From: Guillaume Nodet <gn...@apache.org>
> To: dev@aries.apache.org
> Date: 06/30/2014 01:10 PM
> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> ------------------------------
>
>
>
> This is the first release of a set.
> It contains the parent pom in version 2.0.0
>
> Staging repository available at
> https://repository.apache.org/content/repositories/orgapachearies-1002
>
> [ ] +1 Release parent 2.0.0
> [ ] -1 Do not
>
> Cheers,
> Guillaume Nodet
>
>
Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release
Apache Aries Parent 2.0.0)
Posted by Thomas Watson <tj...@us.ibm.com>.
Isn't there some staging maven repo we can configure into our build that
points to our pre-release (non-SNAPSHOT) artifacts such that our builds can
continue while we are in release limbo?
Tom
From: Jeremy Hughes <jp...@gmail.com>
To: dev@aries.apache.org
Date: 06/30/2014 03:51 PM
Subject: Top down build of trunk failing during release process (was:
Re: [VOTE] Release Apache Aries Parent 2.0.0)
After the release candidate artifacts are posted, module poms have their
version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are being
released at the same time were depending on 2.0.0-SNAPSHOT and moved to
depend on 2.0.0 as part of their own release process. Which is fine for
reviewing the release artifacts of all those modules together. However, the
part of the release process that bumps a module's version in trunk
subsequent to the tagging, doesn't bump the dependency versions. They
shouldn't: a) there's no reason to depend on snapshot b) it doesn't know
the module it depends on is being released at the same time and therefore
isn't available in a repository.
Our process for releasing modules together that have dependencies between
them, is causing the trunk build to be broken while the release vote is
ongoing. I'm not sure what other multi-module projects do and why we're
different, but surely they don't all suffer from this.
Any ideas?
On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> I'm new here and this may be obvious to others. While we are in release
> mode, is it expected that trunk will no longer build due to references to
> the unreleased 2.0.0 parent pom? Is there a good process to follow in
> order to be able to build everything locally while doing other work that
is
> not in the middle of being released?
>
> Tom
>
>
>
> [image: Inactive hide details for Guillaume Nodet ---06/30/2014 01:10:56
> PM---This is the first release of a set. It contains the paren]Guillaume
> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set. It
> contains the parent pom in version 2.0.0
>
> From: Guillaume Nodet <gn...@apache.org>
> To: dev@aries.apache.org
> Date: 06/30/2014 01:10 PM
> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> ------------------------------
>
>
>
> This is the first release of a set.
> It contains the parent pom in version 2.0.0
>
> Staging repository available at
> https://repository.apache.org/content/repositories/orgapachearies-1002
>
> [ ] +1 Release parent 2.0.0
> [ ] -1 Do not
>
> Cheers,
> Guillaume Nodet
>
>
Re: Top down build of trunk failing during release process (was: Re:
[VOTE] Release Apache Aries Parent 2.0.0)
Posted by Guillaume Nodet <gn...@apache.org>.
Deploying a snapshot would not help in that case, because the modification
i've had to make for the release is about upgrading from snapshots to
releases which are not available yet.
I've fixed the build by uploading a 2.0.1-SNAPSHOT of parent and switching
the being-released modules to it.
2014-07-01 9:36 GMT+02:00 David Bosschaert <da...@gmail.com>:
> Yep - the Felix release process outlines this deployment of a snapshot
> just before doing the actual release. I think it would make sense for
> Aries to follow that too:
>
> http://felix.apache.org/documentation/development/release-management-nexus.html
>
> David
>
> On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> >
> > The normal process would be to immediately upon building the “release”,
> do a deploy of the new snapshot version and update everything that
> references the old snapshot to the new snapshot. Thus, things would
> continue to build.
> >
> > Dan
> >
> >
> > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com> wrote:
> >
> >> After the release candidate artifacts are posted, module poms have their
> >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> being
> >> released at the same time were depending on 2.0.0-SNAPSHOT and moved to
> >> depend on 2.0.0 as part of their own release process. Which is fine for
> >> reviewing the release artifacts of all those modules together. However,
> the
> >> part of the release process that bumps a module's version in trunk
> >> subsequent to the tagging, doesn't bump the dependency versions. They
> >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't know
> >> the module it depends on is being released at the same time and
> therefore
> >> isn't available in a repository.
> >>
> >> Our process for releasing modules together that have dependencies
> between
> >> them, is causing the trunk build to be broken while the release vote is
> >> ongoing. I'm not sure what other multi-module projects do and why we're
> >> different, but surely they don't all suffer from this.
> >>
> >> Any ideas?
> >>
> >>
> >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> >>
> >>> I'm new here and this may be obvious to others. While we are in
> release
> >>> mode, is it expected that trunk will no longer build due to references
> to
> >>> the unreleased 2.0.0 parent pom? Is there a good process to follow in
> >>> order to be able to build everything locally while doing other work
> that is
> >>> not in the middle of being released?
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> 01:10:56
> >>> PM---This is the first release of a set. It contains the
> paren]Guillaume
> >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set.
> It
> >>> contains the parent pom in version 2.0.0
> >>>
> >>> From: Guillaume Nodet <gn...@apache.org>
> >>> To: dev@aries.apache.org
> >>> Date: 06/30/2014 01:10 PM
> >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> >>> ------------------------------
> >>>
> >>>
> >>>
> >>> This is the first release of a set.
> >>> It contains the parent pom in version 2.0.0
> >>>
> >>> Staging repository available at
> >>> https://repository.apache.org/content/repositories/orgapachearies-1002
> >>>
> >>> [ ] +1 Release parent 2.0.0
> >>> [ ] -1 Do not
> >>>
> >>> Cheers,
> >>> Guillaume Nodet
> >>>
> >>>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
Re: Top down build of trunk failing during release process (was: Re:
[VOTE] Release Apache Aries Parent 2.0.0)
Posted by Guillaume Nodet <gn...@apache.org>.
I haven't tried, but if you use the -Pdev option for maven (enabling the
dev profile) when building , it should use the snapshot version of the
dependencies.
2014-07-01 16:13 GMT+02:00 Thomas Watson <tj...@us.ibm.com>:
> But that is not enough because there are other dependencies on artifacts
> that are not publically available yet. For example, I still get this error
> building blueprint out of trunk:
>
> [ERROR] Failed to execute goal on project org.apache.aries.blueprint.core:
> Could not resolve dependencies for project
> org.apache.aries.blueprint:org.apache.aries.blueprint.core:bundle:1.4.2-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.aries.blueprint:blueprint-parser:jar:1.2.1,
> org.apache.aries.proxy:org.apache.aries.proxy.impl:jar:1.0.3: Could not
> find artifact org.apache.aries.blueprint:blueprint-parser:jar:1.2.1 in
> EclipseLink Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/)
> -> [Help 1]
>
> That is why I was asking if we can temporarily use a staging maven repo
> for the artifacts that are under review to be released. I don't think
> updating all the references to use the next SNAPSHOT version is correct.
> Right after the release we would then go back to change them back to
> reference the real release?
>
> Tom
>
>
>
> [image: Inactive hide details for Guillaume Nodet ---07/01/2014 03:51:56
> AM---Again, deployment of a snapshot is not the issue here. Th]Guillaume
> Nodet ---07/01/2014 03:51:56 AM---Again, deployment of a snapshot is not
> the issue here. The problem is that artifacts being released
>
>
> From: Guillaume Nodet <gn...@apache.org>
> To: dev@aries.apache.org
> Date: 07/01/2014 03:51 AM
> Subject: Re: Top down build of trunk failing during release process (was:
> Re: [VOTE] Release Apache Aries Parent 2.0.0)
> ------------------------------
>
>
>
> Again, deployment of a snapshot is not the issue here.
> The problem is that artifacts being released use the parent 2.0.0 which is
> not publicly available yet.
> Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so everything
> should be sorted.
>
>
> 2014-07-01 10:45 GMT+02:00 Holly Cummins <ho...@googlemail.com>:
>
> > Our release instructions also include the deployment step:
> > http://aries.apache.org/development/releasingaries.html
> >
> > In the discussion of the release strategy (incremental vs trunk-breaking)
> > they don't include the detail about preferring to depend on releases,
> which
> > might be worth adding.
> >
> > Holly
> >
> >
> > On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <
> > david.bosschaert@gmail.com
> > > wrote:
> >
> > > Yep - the Felix release process outlines this deployment of a snapshot
> > > just before doing the actual release. I think it would make sense for
> > > Aries to follow that too:
> > >
> > >
> >
> http://felix.apache.org/documentation/development/release-management-nexus.html
> > >
> > > David
> > >
> > > On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> > > >
> > > > The normal process would be to immediately upon building the
> “release”,
> > > do a deploy of the new snapshot version and update everything that
> > > references the old snapshot to the new snapshot. Thus, things would
> > > continue to build.
> > > >
> > > > Dan
> > > >
> > > >
> > > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com>
> > wrote:
> > > >
> > > >> After the release candidate artifacts are posted, module poms have
> > their
> > > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> > > being
> > > >> released at the same time were depending on 2.0.0-SNAPSHOT and moved
> > to
> > > >> depend on 2.0.0 as part of their own release process. Which is fine
> > for
> > > >> reviewing the release artifacts of all those modules together.
> > However,
> > > the
> > > >> part of the release process that bumps a module's version in trunk
> > > >> subsequent to the tagging, doesn't bump the dependency versions.
> They
> > > >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't
> > know
> > > >> the module it depends on is being released at the same time and
> > > therefore
> > > >> isn't available in a repository.
> > > >>
> > > >> Our process for releasing modules together that have dependencies
> > > between
> > > >> them, is causing the trunk build to be broken while the release vote
> > is
> > > >> ongoing. I'm not sure what other multi-module projects do and why
> > we're
> > > >> different, but surely they don't all suffer from this.
> > > >>
> > > >> Any ideas?
> > > >>
> > > >>
> > > >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> > > >>
> > > >>> I'm new here and this may be obvious to others. While we are in
> > > release
> > > >>> mode, is it expected that trunk will no longer build due to
> > references
> > > to
> > > >>> the unreleased 2.0.0 parent pom? Is there a good process to follow
> > in
> > > >>> order to be able to build everything locally while doing other work
> > > that is
> > > >>> not in the middle of being released?
> > > >>>
> > > >>> Tom
> > > >>>
> > > >>>
> > > >>>
> > > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> > > 01:10:56
> > > >>> PM---This is the first release of a set. It contains the
> > > paren]Guillaume
> > > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a
> set.
> > > It
> > > >>> contains the parent pom in version 2.0.0
> > > >>>
> > > >>> From: Guillaume Nodet <gn...@apache.org>
> > > >>> To: dev@aries.apache.org
> > > >>> Date: 06/30/2014 01:10 PM
> > > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> > > >>> ------------------------------
> > > >>>
> > > >>>
> > > >>>
> > > >>> This is the first release of a set.
> > > >>> It contains the parent pom in version 2.0.0
> > > >>>
> > > >>> Staging repository available at
> > > >>>
> > https://repository.apache.org/content/repositories/orgapachearies-1002
> > > >>>
> > > >>> [ ] +1 Release parent 2.0.0
> > > >>> [ ] -1 Do not
> > > >>>
> > > >>> Cheers,
> > > >>> Guillaume Nodet
> > > >>>
> > > >>>
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org - http://dankulp.com/blog
> > > > Talend Community Coder - http://coders.talend.com
> > > >
> > >
> >
>
>
Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
Posted by Holly Cummins <ho...@googlemail.com>.
Hi Tom,
Agree 100%, we want to always have a trunk that builds. The ways we can do this (IMO, in rough order of ease/desirability) are:
0. Always do a deploy during a release.
1. Avoid depending on snapshots except where, as you say, it is necessary.
2. Avoid doing releases of multiple bundles at the same time, if there are interdependencies (for example, releasing parent and blueprint at the same time). The downside of this is it means releases of large sets of bundles can be involve serious elapsed time, once all the vote windows are allowed between releases. When I released 1.0 without breaking trunk it took over a month.
4. Make temporary changes after preparing the release to patch things up into a buildable state.
Your idea of using the staging repos is I guess a variant of 4. and also does get us unbroken. It seems a shame to have to do it but it's definitely better than being broken during the vote.
Holly
> On 1 Jul 2014, at 20:34, Thomas Watson <tj...@us.ibm.com> wrote:
>
> Hi Holly,
>
> I appreciate your point, and agree that we should strive to build against the lowest possible version of our dependency artifacts. Otherwise I think we may end up with import ranges that exclude valid previous versions.
>
> But lets make the assumption that we will from time to time release several modules in Aries that do really need to depend on the latest and greatest from other modules that we want to release at the "same time". In this case I think trunk must be left in a state that can build. Is it not possible to temporarily configure in the staging repos that Guillaume referenced?
>
> Technically, the answer is yes. I added the following to the parent pom and it did end up building successfully:
>
> <repository>
> <id>Aries release review staging 1002</id>
> <url>https://repository.apache.org/content/repositories/orgapachearies-1002/</url>
> </repository>
> <repository>
> <id>Aries release review staging 1003</id>
> <url>https://repository.apache.org/content/repositories/orgapachearies-1003/</url>
> </repository>
> <repository>
> <id>Aries release review staging 1004</id>
> <url>https://repository.apache.org/content/repositories/orgapachearies-1004/</url>
> </repository>
> <repository>
> <id>Aries release review staging 1005</id>
> <url>https://repository.apache.org/content/repositories/orgapachearies-1005/</url>
> </repository>
>
> Is that the correct thing to do? I don't really know but it does seem nicer than having a broken trunk build while waiting for a release vote to occur. This is what I meant by using the staging repos.
>
> Tom
>
>
>
> Holly Cummins ---07/01/2014 01:16:07 PM---This is perhaps where my point about over-use of the snapshot dependencies and the versioning applie
>
> From: Holly Cummins <ho...@googlemail.com>
> To: "dev@aries.apache.org" <de...@aries.apache.org>
> Date: 07/01/2014 01:16 PM
> Subject: Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
>
>
>
> This is perhaps where my point about over-use of the snapshot dependencies and the versioning applies. For example, does blueprint core now need parser-1.2.1 rather than parser-1.2.0 to function correctly?
>
> > On 1 Jul 2014, at 15:13, Thomas Watson <tj...@us.ibm.com> wrote:
> >
> > But that is not enough because there are other dependencies on artifacts that are not publically available yet. For example, I still get this error building blueprint out of trunk:
> >
> > [ERROR] Failed to execute goal on project org.apache.aries.blueprint.core: Could not resolve dependencies for project org.apache.aries.blueprint:org.apache.aries.blueprint.core:bundle:1.4.2-SNAPSHOT: The following artifacts could not be resolved: org.apache.aries.blueprint:blueprint-parser:jar:1.2.1, org.apache.aries.proxy:org.apache.aries.proxy.impl:jar:1.0.3: Could not find artifact org.apache.aries.blueprint:blueprint-parser:jar:1.2.1 in EclipseLink Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/) -> [Help 1]
> >
> > That is why I was asking if we can temporarily use a staging maven repo for the artifacts that are under review to be released. I don't think updating all the references to use the next SNAPSHOT version is correct. Right after the release we would then go back to change them back to reference the real release?
> >
> > Tom
> >
> >
> >
> > Guillaume Nodet ---07/01/2014 03:51:56 AM---Again, deployment of a snapshot is not the issue here. The problem is that artifacts being released
> >
> > From: Guillaume Nodet <gn...@apache.org>
> > To: dev@aries.apache.org
> > Date: 07/01/2014 03:51 AM
> > Subject: Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
> >
> >
> >
> > Again, deployment of a snapshot is not the issue here.
> > The problem is that artifacts being released use the parent 2.0.0 which is
> > not publicly available yet.
> > Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so everything
> > should be sorted.
> >
> >
> > 2014-07-01 10:45 GMT+02:00 Holly Cummins <ho...@googlemail.com>:
> >
> > > Our release instructions also include the deployment step:
> > > http://aries.apache.org/development/releasingaries.html
> > >
> > > In the discussion of the release strategy (incremental vs trunk-breaking)
> > > they don't include the detail about preferring to depend on releases, which
> > > might be worth adding.
> > >
> > > Holly
> > >
> > >
> > > On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <
> > > david.bosschaert@gmail.com
> > > > wrote:
> > >
> > > > Yep - the Felix release process outlines this deployment of a snapshot
> > > > just before doing the actual release. I think it would make sense for
> > > > Aries to follow that too:
> > > >
> > > >
> > > http://felix.apache.org/documentation/development/release-management-nexus.html
> > > >
> > > > David
> > > >
> > > > On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> > > > >
> > > > > The normal process would be to immediately upon building the “release”,
> > > > do a deploy of the new snapshot version and update everything that
> > > > references the old snapshot to the new snapshot. Thus, things would
> > > > continue to build.
> > > > >
> > > > > Dan
> > > > >
> > > > >
> > > > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com>
> > > wrote:
> > > > >
> > > > >> After the release candidate artifacts are posted, module poms have
> > > their
> > > > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> > > > being
> > > > >> released at the same time were depending on 2.0.0-SNAPSHOT and moved
> > > to
> > > > >> depend on 2.0.0 as part of their own release process. Which is fine
> > > for
> > > > >> reviewing the release artifacts of all those modules together.
> > > However,
> > > > the
> > > > >> part of the release process that bumps a module's version in trunk
> > > > >> subsequent to the tagging, doesn't bump the dependency versions. They
> > > > >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't
> > > know
> > > > >> the module it depends on is being released at the same time and
> > > > therefore
> > > > >> isn't available in a repository.
> > > > >>
> > > > >> Our process for releasing modules together that have dependencies
> > > > between
> > > > >> them, is causing the trunk build to be broken while the release vote
> > > is
> > > > >> ongoing. I'm not sure what other multi-module projects do and why
> > > we're
> > > > >> different, but surely they don't all suffer from this.
> > > > >>
> > > > >> Any ideas?
> > > > >>
> > > > >>
> > > > >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> > > > >>
> > > > >>> I'm new here and this may be obvious to others. While we are in
> > > > release
> > > > >>> mode, is it expected that trunk will no longer build due to
> > > references
> > > > to
> > > > >>> the unreleased 2.0.0 parent pom? Is there a good process to follow
> > > in
> > > > >>> order to be able to build everything locally while doing other work
> > > > that is
> > > > >>> not in the middle of being released?
> > > > >>>
> > > > >>> Tom
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> > > > 01:10:56
> > > > >>> PM---This is the first release of a set. It contains the
> > > > paren]Guillaume
> > > > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set.
> > > > It
> > > > >>> contains the parent pom in version 2.0.0
> > > > >>>
> > > > >>> From: Guillaume Nodet <gn...@apache.org>
> > > > >>> To: dev@aries.apache.org
> > > > >>> Date: 06/30/2014 01:10 PM
> > > > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> > > > >>> ------------------------------
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> This is the first release of a set.
> > > > >>> It contains the parent pom in version 2.0.0
> > > > >>>
> > > > >>> Staging repository available at
> > > > >>>
> > > https://repository.apache.org/content/repositories/orgapachearies-1002
> > > > >>>
> > > > >>> [ ] +1 Release parent 2.0.0
> > > > >>> [ ] -1 Do not
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Guillaume Nodet
> > > > >>>
> > > > >>>
> > > > >
> > > > > --
> > > > > Daniel Kulp
> > > > > dkulp@apache.org - http://dankulp.com/blog
> > > > > Talend Community Coder - http://coders.talend.com
> > > > >
> > > >
> > >
> >
>
Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release
Apache Aries Parent 2.0.0)
Posted by Thomas Watson <tj...@us.ibm.com>.
Hi Holly,
I appreciate your point, and agree that we should strive to build against
the lowest possible version of our dependency artifacts. Otherwise I think
we may end up with import ranges that exclude valid previous versions.
But lets make the assumption that we will from time to time release
several modules in Aries that do really need to depend on the latest and
greatest from other modules that we want to release at the "same time". In
this case I think trunk must be left in a state that can build. Is it not
possible to temporarily configure in the staging repos that Guillaume
referenced?
Technically, the answer is yes. I added the following to the parent pom
and it did end up building successfully:
<repository>
<id>Aries release review staging 1002</id>
<url>
https://repository.apache.org/content/repositories/orgapachearies-1002/
</url>
</repository>
<repository>
<id>Aries release review staging 1003</id>
<url>
https://repository.apache.org/content/repositories/orgapachearies-1003/
</url>
</repository>
<repository>
<id>Aries release review staging 1004</id>
<url>
https://repository.apache.org/content/repositories/orgapachearies-1004/
</url>
</repository>
<repository>
<id>Aries release review staging 1005</id>
<url>
https://repository.apache.org/content/repositories/orgapachearies-1005/
</url>
</repository>
Is that the correct thing to do? I don't really know but it does seem
nicer than having a broken trunk build while waiting for a release vote to
occur. This is what I meant by using the staging repos.
Tom
From: Holly Cummins <ho...@googlemail.com>
To: "dev@aries.apache.org" <de...@aries.apache.org>
Date: 07/01/2014 01:16 PM
Subject: Re: Top down build of trunk failing during release process
(was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
This is perhaps where my point about over-use of the snapshot dependencies
and the versioning applies. For example, does blueprint core now need
parser-1.2.1 rather than parser-1.2.0 to function correctly?
> On 1 Jul 2014, at 15:13, Thomas Watson <tj...@us.ibm.com> wrote:
>
> But that is not enough because there are other dependencies on artifacts
that are not publically available yet. For example, I still get this error
building blueprint out of trunk:
>
> [ERROR] Failed to execute goal on project
org.apache.aries.blueprint.core: Could not resolve dependencies for project
org.apache.aries.blueprint:org.apache.aries.blueprint.core:bundle:1.4.2-SNAPSHOT:
The following artifacts could not be resolved:
org.apache.aries.blueprint:blueprint-parser:jar:1.2.1,
org.apache.aries.proxy:org.apache.aries.proxy.impl:jar:1.0.3: Could not
find artifact org.apache.aries.blueprint:blueprint-parser:jar:1.2.1 in
EclipseLink Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/)
-> [Help 1]
>
> That is why I was asking if we can temporarily use a staging maven repo
for the artifacts that are under review to be released. I don't think
updating all the references to use the next SNAPSHOT version is correct.
Right after the release we would then go back to change them back to
reference the real release?
>
> Tom
>
>
>
> Guillaume Nodet ---07/01/2014 03:51:56 AM---Again, deployment of a
snapshot is not the issue here. The problem is that artifacts being
released
>
> From: Guillaume Nodet <gn...@apache.org>
> To: dev@aries.apache.org
> Date: 07/01/2014 03:51 AM
> Subject: Re: Top down build of trunk failing during release
process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
>
>
>
> Again, deployment of a snapshot is not the issue here.
> The problem is that artifacts being released use the parent 2.0.0 which
is
> not publicly available yet.
> Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so
everything
> should be sorted.
>
>
> 2014-07-01 10:45 GMT+02:00 Holly Cummins
<ho...@googlemail.com>:
>
> > Our release instructions also include the deployment step:
> > http://aries.apache.org/development/releasingaries.html
> >
> > In the discussion of the release strategy (incremental vs
trunk-breaking)
> > they don't include the detail about preferring to depend on releases,
which
> > might be worth adding.
> >
> > Holly
> >
> >
> > On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <
> > david.bosschaert@gmail.com
> > > wrote:
> >
> > > Yep - the Felix release process outlines this deployment of a
snapshot
> > > just before doing the actual release. I think it would make sense for
> > > Aries to follow that too:
> > >
> > >
> >
http://felix.apache.org/documentation/development/release-management-nexus.html
> > >
> > > David
> > >
> > > On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> > > >
> > > > The normal process would be to immediately upon building the
“release”,
> > > do a deploy of the new snapshot version and update everything that
> > > references the old snapshot to the new snapshot. Thus, things would
> > > continue to build.
> > > >
> > > > Dan
> > > >
> > > >
> > > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com>
> > wrote:
> > > >
> > > >> After the release candidate artifacts are posted, module poms have
> > their
> > > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that
are
> > > being
> > > >> released at the same time were depending on 2.0.0-SNAPSHOT and
moved
> > to
> > > >> depend on 2.0.0 as part of their own release process. Which is
fine
> > for
> > > >> reviewing the release artifacts of all those modules together.
> > However,
> > > the
> > > >> part of the release process that bumps a module's version in trunk
> > > >> subsequent to the tagging, doesn't bump the dependency versions.
They
> > > >> shouldn't: a) there's no reason to depend on snapshot b) it
doesn't
> > know
> > > >> the module it depends on is being released at the same time and
> > > therefore
> > > >> isn't available in a repository.
> > > >>
> > > >> Our process for releasing modules together that have dependencies
> > > between
> > > >> them, is causing the trunk build to be broken while the release
vote
> > is
> > > >> ongoing. I'm not sure what other multi-module projects do and why
> > we're
> > > >> different, but surely they don't all suffer from this.
> > > >>
> > > >> Any ideas?
> > > >>
> > > >>
> > > >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> > > >>
> > > >>> I'm new here and this may be obvious to others. While we are in
> > > release
> > > >>> mode, is it expected that trunk will no longer build due to
> > references
> > > to
> > > >>> the unreleased 2.0.0 parent pom? Is there a good process to
follow
> > in
> > > >>> order to be able to build everything locally while doing other
work
> > > that is
> > > >>> not in the middle of being released?
> > > >>>
> > > >>> Tom
> > > >>>
> > > >>>
> > > >>>
> > > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> > > 01:10:56
> > > >>> PM---This is the first release of a set. It contains the
> > > paren]Guillaume
> > > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a
set.
> > > It
> > > >>> contains the parent pom in version 2.0.0
> > > >>>
> > > >>> From: Guillaume Nodet <gn...@apache.org>
> > > >>> To: dev@aries.apache.org
> > > >>> Date: 06/30/2014 01:10 PM
> > > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> > > >>> ------------------------------
> > > >>>
> > > >>>
> > > >>>
> > > >>> This is the first release of a set.
> > > >>> It contains the parent pom in version 2.0.0
> > > >>>
> > > >>> Staging repository available at
> > > >>>
> > https://repository.apache.org/content/repositories/orgapachearies-1002
> > > >>>
> > > >>> [ ] +1 Release parent 2.0.0
> > > >>> [ ] -1 Do not
> > > >>>
> > > >>> Cheers,
> > > >>> Guillaume Nodet
> > > >>>
> > > >>>
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org - http://dankulp.com/blog
> > > > Talend Community Coder - http://coders.talend.com
> > > >
> > >
> >
>
Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
Posted by Holly Cummins <ho...@googlemail.com>.
This is perhaps where my point about over-use of the snapshot dependencies and the versioning applies. For example, does blueprint core now need parser-1.2.1 rather than parser-1.2.0 to function correctly?
> On 1 Jul 2014, at 15:13, Thomas Watson <tj...@us.ibm.com> wrote:
>
> But that is not enough because there are other dependencies on artifacts that are not publically available yet. For example, I still get this error building blueprint out of trunk:
>
> [ERROR] Failed to execute goal on project org.apache.aries.blueprint.core: Could not resolve dependencies for project org.apache.aries.blueprint:org.apache.aries.blueprint.core:bundle:1.4.2-SNAPSHOT: The following artifacts could not be resolved: org.apache.aries.blueprint:blueprint-parser:jar:1.2.1, org.apache.aries.proxy:org.apache.aries.proxy.impl:jar:1.0.3: Could not find artifact org.apache.aries.blueprint:blueprint-parser:jar:1.2.1 in EclipseLink Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/) -> [Help 1]
>
> That is why I was asking if we can temporarily use a staging maven repo for the artifacts that are under review to be released. I don't think updating all the references to use the next SNAPSHOT version is correct. Right after the release we would then go back to change them back to reference the real release?
>
> Tom
>
>
>
> Guillaume Nodet ---07/01/2014 03:51:56 AM---Again, deployment of a snapshot is not the issue here. The problem is that artifacts being released
>
> From: Guillaume Nodet <gn...@apache.org>
> To: dev@aries.apache.org
> Date: 07/01/2014 03:51 AM
> Subject: Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
>
>
>
> Again, deployment of a snapshot is not the issue here.
> The problem is that artifacts being released use the parent 2.0.0 which is
> not publicly available yet.
> Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so everything
> should be sorted.
>
>
> 2014-07-01 10:45 GMT+02:00 Holly Cummins <ho...@googlemail.com>:
>
> > Our release instructions also include the deployment step:
> > http://aries.apache.org/development/releasingaries.html
> >
> > In the discussion of the release strategy (incremental vs trunk-breaking)
> > they don't include the detail about preferring to depend on releases, which
> > might be worth adding.
> >
> > Holly
> >
> >
> > On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <
> > david.bosschaert@gmail.com
> > > wrote:
> >
> > > Yep - the Felix release process outlines this deployment of a snapshot
> > > just before doing the actual release. I think it would make sense for
> > > Aries to follow that too:
> > >
> > >
> > http://felix.apache.org/documentation/development/release-management-nexus.html
> > >
> > > David
> > >
> > > On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> > > >
> > > > The normal process would be to immediately upon building the “release”,
> > > do a deploy of the new snapshot version and update everything that
> > > references the old snapshot to the new snapshot. Thus, things would
> > > continue to build.
> > > >
> > > > Dan
> > > >
> > > >
> > > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com>
> > wrote:
> > > >
> > > >> After the release candidate artifacts are posted, module poms have
> > their
> > > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> > > being
> > > >> released at the same time were depending on 2.0.0-SNAPSHOT and moved
> > to
> > > >> depend on 2.0.0 as part of their own release process. Which is fine
> > for
> > > >> reviewing the release artifacts of all those modules together.
> > However,
> > > the
> > > >> part of the release process that bumps a module's version in trunk
> > > >> subsequent to the tagging, doesn't bump the dependency versions. They
> > > >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't
> > know
> > > >> the module it depends on is being released at the same time and
> > > therefore
> > > >> isn't available in a repository.
> > > >>
> > > >> Our process for releasing modules together that have dependencies
> > > between
> > > >> them, is causing the trunk build to be broken while the release vote
> > is
> > > >> ongoing. I'm not sure what other multi-module projects do and why
> > we're
> > > >> different, but surely they don't all suffer from this.
> > > >>
> > > >> Any ideas?
> > > >>
> > > >>
> > > >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> > > >>
> > > >>> I'm new here and this may be obvious to others. While we are in
> > > release
> > > >>> mode, is it expected that trunk will no longer build due to
> > references
> > > to
> > > >>> the unreleased 2.0.0 parent pom? Is there a good process to follow
> > in
> > > >>> order to be able to build everything locally while doing other work
> > > that is
> > > >>> not in the middle of being released?
> > > >>>
> > > >>> Tom
> > > >>>
> > > >>>
> > > >>>
> > > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> > > 01:10:56
> > > >>> PM---This is the first release of a set. It contains the
> > > paren]Guillaume
> > > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set.
> > > It
> > > >>> contains the parent pom in version 2.0.0
> > > >>>
> > > >>> From: Guillaume Nodet <gn...@apache.org>
> > > >>> To: dev@aries.apache.org
> > > >>> Date: 06/30/2014 01:10 PM
> > > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> > > >>> ------------------------------
> > > >>>
> > > >>>
> > > >>>
> > > >>> This is the first release of a set.
> > > >>> It contains the parent pom in version 2.0.0
> > > >>>
> > > >>> Staging repository available at
> > > >>>
> > https://repository.apache.org/content/repositories/orgapachearies-1002
> > > >>>
> > > >>> [ ] +1 Release parent 2.0.0
> > > >>> [ ] -1 Do not
> > > >>>
> > > >>> Cheers,
> > > >>> Guillaume Nodet
> > > >>>
> > > >>>
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org - http://dankulp.com/blog
> > > > Talend Community Coder - http://coders.talend.com
> > > >
> > >
> >
>
Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release
Apache Aries Parent 2.0.0)
Posted by Thomas Watson <tj...@us.ibm.com>.
But that is not enough because there are other dependencies on artifacts
that are not publically available yet. For example, I still get this error
building blueprint out of trunk:
[ERROR] Failed to execute goal on project org.apache.aries.blueprint.core:
Could not resolve dependencies for project
org.apache.aries.blueprint:org.apache.aries.blueprint.core:bundle:1.4.2-SNAPSHOT:
The following artifacts could not be resolved:
org.apache.aries.blueprint:blueprint-parser:jar:1.2.1,
org.apache.aries.proxy:org.apache.aries.proxy.impl:jar:1.0.3: Could not
find artifact org.apache.aries.blueprint:blueprint-parser:jar:1.2.1 in
EclipseLink Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/)
-> [Help 1]
That is why I was asking if we can temporarily use a staging maven repo for
the artifacts that are under review to be released. I don't think updating
all the references to use the next SNAPSHOT version is correct. Right
after the release we would then go back to change them back to reference
the real release?
Tom
From: Guillaume Nodet <gn...@apache.org>
To: dev@aries.apache.org
Date: 07/01/2014 03:51 AM
Subject: Re: Top down build of trunk failing during release process
(was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
Again, deployment of a snapshot is not the issue here.
The problem is that artifacts being released use the parent 2.0.0 which is
not publicly available yet.
Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so everything
should be sorted.
2014-07-01 10:45 GMT+02:00 Holly Cummins <ho...@googlemail.com>:
> Our release instructions also include the deployment step:
> http://aries.apache.org/development/releasingaries.html
>
> In the discussion of the release strategy (incremental vs trunk-breaking)
> they don't include the detail about preferring to depend on releases,
which
> might be worth adding.
>
> Holly
>
>
> On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <
> david.bosschaert@gmail.com
> > wrote:
>
> > Yep - the Felix release process outlines this deployment of a snapshot
> > just before doing the actual release. I think it would make sense for
> > Aries to follow that too:
> >
> >
>
http://felix.apache.org/documentation/development/release-management-nexus.html
> >
> > David
> >
> > On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> > >
> > > The normal process would be to immediately upon building the
“release”,
> > do a deploy of the new snapshot version and update everything that
> > references the old snapshot to the new snapshot. Thus, things would
> > continue to build.
> > >
> > > Dan
> > >
> > >
> > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com>
> wrote:
> > >
> > >> After the release candidate artifacts are posted, module poms have
> their
> > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> > being
> > >> released at the same time were depending on 2.0.0-SNAPSHOT and moved
> to
> > >> depend on 2.0.0 as part of their own release process. Which is fine
> for
> > >> reviewing the release artifacts of all those modules together.
> However,
> > the
> > >> part of the release process that bumps a module's version in trunk
> > >> subsequent to the tagging, doesn't bump the dependency versions.
They
> > >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't
> know
> > >> the module it depends on is being released at the same time and
> > therefore
> > >> isn't available in a repository.
> > >>
> > >> Our process for releasing modules together that have dependencies
> > between
> > >> them, is causing the trunk build to be broken while the release vote
> is
> > >> ongoing. I'm not sure what other multi-module projects do and why
> we're
> > >> different, but surely they don't all suffer from this.
> > >>
> > >> Any ideas?
> > >>
> > >>
> > >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> > >>
> > >>> I'm new here and this may be obvious to others. While we are in
> > release
> > >>> mode, is it expected that trunk will no longer build due to
> references
> > to
> > >>> the unreleased 2.0.0 parent pom? Is there a good process to follow
> in
> > >>> order to be able to build everything locally while doing other work
> > that is
> > >>> not in the middle of being released?
> > >>>
> > >>> Tom
> > >>>
> > >>>
> > >>>
> > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> > 01:10:56
> > >>> PM---This is the first release of a set. It contains the
> > paren]Guillaume
> > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a
set.
> > It
> > >>> contains the parent pom in version 2.0.0
> > >>>
> > >>> From: Guillaume Nodet <gn...@apache.org>
> > >>> To: dev@aries.apache.org
> > >>> Date: 06/30/2014 01:10 PM
> > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> > >>> ------------------------------
> > >>>
> > >>>
> > >>>
> > >>> This is the first release of a set.
> > >>> It contains the parent pom in version 2.0.0
> > >>>
> > >>> Staging repository available at
> > >>>
> https://repository.apache.org/content/repositories/orgapachearies-1002
> > >>>
> > >>> [ ] +1 Release parent 2.0.0
> > >>> [ ] -1 Do not
> > >>>
> > >>> Cheers,
> > >>> Guillaume Nodet
> > >>>
> > >>>
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> >
>
Re: Top down build of trunk failing during release process (was: Re:
[VOTE] Release Apache Aries Parent 2.0.0)
Posted by Guillaume Nodet <gn...@apache.org>.
Again, deployment of a snapshot is not the issue here.
The problem is that artifacts being released use the parent 2.0.0 which is
not publicly available yet.
Anyway, I've moved those bundles to use parent 2.0.1-SNAPSHOT so everything
should be sorted.
2014-07-01 10:45 GMT+02:00 Holly Cummins <ho...@googlemail.com>:
> Our release instructions also include the deployment step:
> http://aries.apache.org/development/releasingaries.html
>
> In the discussion of the release strategy (incremental vs trunk-breaking)
> they don't include the detail about preferring to depend on releases, which
> might be worth adding.
>
> Holly
>
>
> On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <
> david.bosschaert@gmail.com
> > wrote:
>
> > Yep - the Felix release process outlines this deployment of a snapshot
> > just before doing the actual release. I think it would make sense for
> > Aries to follow that too:
> >
> >
> http://felix.apache.org/documentation/development/release-management-nexus.html
> >
> > David
> >
> > On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> > >
> > > The normal process would be to immediately upon building the “release”,
> > do a deploy of the new snapshot version and update everything that
> > references the old snapshot to the new snapshot. Thus, things would
> > continue to build.
> > >
> > > Dan
> > >
> > >
> > > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com>
> wrote:
> > >
> > >> After the release candidate artifacts are posted, module poms have
> their
> > >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> > being
> > >> released at the same time were depending on 2.0.0-SNAPSHOT and moved
> to
> > >> depend on 2.0.0 as part of their own release process. Which is fine
> for
> > >> reviewing the release artifacts of all those modules together.
> However,
> > the
> > >> part of the release process that bumps a module's version in trunk
> > >> subsequent to the tagging, doesn't bump the dependency versions. They
> > >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't
> know
> > >> the module it depends on is being released at the same time and
> > therefore
> > >> isn't available in a repository.
> > >>
> > >> Our process for releasing modules together that have dependencies
> > between
> > >> them, is causing the trunk build to be broken while the release vote
> is
> > >> ongoing. I'm not sure what other multi-module projects do and why
> we're
> > >> different, but surely they don't all suffer from this.
> > >>
> > >> Any ideas?
> > >>
> > >>
> > >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> > >>
> > >>> I'm new here and this may be obvious to others. While we are in
> > release
> > >>> mode, is it expected that trunk will no longer build due to
> references
> > to
> > >>> the unreleased 2.0.0 parent pom? Is there a good process to follow
> in
> > >>> order to be able to build everything locally while doing other work
> > that is
> > >>> not in the middle of being released?
> > >>>
> > >>> Tom
> > >>>
> > >>>
> > >>>
> > >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> > 01:10:56
> > >>> PM---This is the first release of a set. It contains the
> > paren]Guillaume
> > >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set.
> > It
> > >>> contains the parent pom in version 2.0.0
> > >>>
> > >>> From: Guillaume Nodet <gn...@apache.org>
> > >>> To: dev@aries.apache.org
> > >>> Date: 06/30/2014 01:10 PM
> > >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> > >>> ------------------------------
> > >>>
> > >>>
> > >>>
> > >>> This is the first release of a set.
> > >>> It contains the parent pom in version 2.0.0
> > >>>
> > >>> Staging repository available at
> > >>>
> https://repository.apache.org/content/repositories/orgapachearies-1002
> > >>>
> > >>> [ ] +1 Release parent 2.0.0
> > >>> [ ] -1 Do not
> > >>>
> > >>> Cheers,
> > >>> Guillaume Nodet
> > >>>
> > >>>
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org - http://dankulp.com/blog
> > > Talend Community Coder - http://coders.talend.com
> > >
> >
>
Re: Top down build of trunk failing during release process (was: Re:
[VOTE] Release Apache Aries Parent 2.0.0)
Posted by Holly Cummins <ho...@googlemail.com>.
Our release instructions also include the deployment step:
http://aries.apache.org/development/releasingaries.html
In the discussion of the release strategy (incremental vs trunk-breaking)
they don't include the detail about preferring to depend on releases, which
might be worth adding.
Holly
On Tue, Jul 1, 2014 at 8:36 AM, David Bosschaert <david.bosschaert@gmail.com
> wrote:
> Yep - the Felix release process outlines this deployment of a snapshot
> just before doing the actual release. I think it would make sense for
> Aries to follow that too:
>
> http://felix.apache.org/documentation/development/release-management-nexus.html
>
> David
>
> On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
> >
> > The normal process would be to immediately upon building the “release”,
> do a deploy of the new snapshot version and update everything that
> references the old snapshot to the new snapshot. Thus, things would
> continue to build.
> >
> > Dan
> >
> >
> > On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com> wrote:
> >
> >> After the release candidate artifacts are posted, module poms have their
> >> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are
> being
> >> released at the same time were depending on 2.0.0-SNAPSHOT and moved to
> >> depend on 2.0.0 as part of their own release process. Which is fine for
> >> reviewing the release artifacts of all those modules together. However,
> the
> >> part of the release process that bumps a module's version in trunk
> >> subsequent to the tagging, doesn't bump the dependency versions. They
> >> shouldn't: a) there's no reason to depend on snapshot b) it doesn't know
> >> the module it depends on is being released at the same time and
> therefore
> >> isn't available in a repository.
> >>
> >> Our process for releasing modules together that have dependencies
> between
> >> them, is causing the trunk build to be broken while the release vote is
> >> ongoing. I'm not sure what other multi-module projects do and why we're
> >> different, but surely they don't all suffer from this.
> >>
> >> Any ideas?
> >>
> >>
> >> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
> >>
> >>> I'm new here and this may be obvious to others. While we are in
> release
> >>> mode, is it expected that trunk will no longer build due to references
> to
> >>> the unreleased 2.0.0 parent pom? Is there a good process to follow in
> >>> order to be able to build everything locally while doing other work
> that is
> >>> not in the middle of being released?
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014
> 01:10:56
> >>> PM---This is the first release of a set. It contains the
> paren]Guillaume
> >>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set.
> It
> >>> contains the parent pom in version 2.0.0
> >>>
> >>> From: Guillaume Nodet <gn...@apache.org>
> >>> To: dev@aries.apache.org
> >>> Date: 06/30/2014 01:10 PM
> >>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
> >>> ------------------------------
> >>>
> >>>
> >>>
> >>> This is the first release of a set.
> >>> It contains the parent pom in version 2.0.0
> >>>
> >>> Staging repository available at
> >>> https://repository.apache.org/content/repositories/orgapachearies-1002
> >>>
> >>> [ ] +1 Release parent 2.0.0
> >>> [ ] -1 Do not
> >>>
> >>> Cheers,
> >>> Guillaume Nodet
> >>>
> >>>
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
Re: Top down build of trunk failing during release process (was: Re:
[VOTE] Release Apache Aries Parent 2.0.0)
Posted by David Bosschaert <da...@gmail.com>.
Yep - the Felix release process outlines this deployment of a snapshot
just before doing the actual release. I think it would make sense for
Aries to follow that too:
http://felix.apache.org/documentation/development/release-management-nexus.html
David
On 30 June 2014 22:27, Daniel Kulp <dk...@apache.org> wrote:
>
> The normal process would be to immediately upon building the “release”, do a deploy of the new snapshot version and update everything that references the old snapshot to the new snapshot. Thus, things would continue to build.
>
> Dan
>
>
> On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com> wrote:
>
>> After the release candidate artifacts are posted, module poms have their
>> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are being
>> released at the same time were depending on 2.0.0-SNAPSHOT and moved to
>> depend on 2.0.0 as part of their own release process. Which is fine for
>> reviewing the release artifacts of all those modules together. However, the
>> part of the release process that bumps a module's version in trunk
>> subsequent to the tagging, doesn't bump the dependency versions. They
>> shouldn't: a) there's no reason to depend on snapshot b) it doesn't know
>> the module it depends on is being released at the same time and therefore
>> isn't available in a repository.
>>
>> Our process for releasing modules together that have dependencies between
>> them, is causing the trunk build to be broken while the release vote is
>> ongoing. I'm not sure what other multi-module projects do and why we're
>> different, but surely they don't all suffer from this.
>>
>> Any ideas?
>>
>>
>> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
>>
>>> I'm new here and this may be obvious to others. While we are in release
>>> mode, is it expected that trunk will no longer build due to references to
>>> the unreleased 2.0.0 parent pom? Is there a good process to follow in
>>> order to be able to build everything locally while doing other work that is
>>> not in the middle of being released?
>>>
>>> Tom
>>>
>>>
>>>
>>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014 01:10:56
>>> PM---This is the first release of a set. It contains the paren]Guillaume
>>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set. It
>>> contains the parent pom in version 2.0.0
>>>
>>> From: Guillaume Nodet <gn...@apache.org>
>>> To: dev@aries.apache.org
>>> Date: 06/30/2014 01:10 PM
>>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
>>> ------------------------------
>>>
>>>
>>>
>>> This is the first release of a set.
>>> It contains the parent pom in version 2.0.0
>>>
>>> Staging repository available at
>>> https://repository.apache.org/content/repositories/orgapachearies-1002
>>>
>>> [ ] +1 Release parent 2.0.0
>>> [ ] -1 Do not
>>>
>>> Cheers,
>>> Guillaume Nodet
>>>
>>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: Top down build of trunk failing during release process (was: Re: [VOTE] Release Apache Aries Parent 2.0.0)
Posted by Daniel Kulp <dk...@apache.org>.
The normal process would be to immediately upon building the “release”, do a deploy of the new snapshot version and update everything that references the old snapshot to the new snapshot. Thus, things would continue to build.
Dan
On Jun 30, 2014, at 4:51 PM, Jeremy Hughes <jp...@gmail.com> wrote:
> After the release candidate artifacts are posted, module poms have their
> version bumped up. So parent is now 2.0.1-SNAPSHOT. Modules that are being
> released at the same time were depending on 2.0.0-SNAPSHOT and moved to
> depend on 2.0.0 as part of their own release process. Which is fine for
> reviewing the release artifacts of all those modules together. However, the
> part of the release process that bumps a module's version in trunk
> subsequent to the tagging, doesn't bump the dependency versions. They
> shouldn't: a) there's no reason to depend on snapshot b) it doesn't know
> the module it depends on is being released at the same time and therefore
> isn't available in a repository.
>
> Our process for releasing modules together that have dependencies between
> them, is causing the trunk build to be broken while the release vote is
> ongoing. I'm not sure what other multi-module projects do and why we're
> different, but surely they don't all suffer from this.
>
> Any ideas?
>
>
> On 30 June 2014 19:53, Thomas Watson <tj...@us.ibm.com> wrote:
>
>> I'm new here and this may be obvious to others. While we are in release
>> mode, is it expected that trunk will no longer build due to references to
>> the unreleased 2.0.0 parent pom? Is there a good process to follow in
>> order to be able to build everything locally while doing other work that is
>> not in the middle of being released?
>>
>> Tom
>>
>>
>>
>> [image: Inactive hide details for Guillaume Nodet ---06/30/2014 01:10:56
>> PM---This is the first release of a set. It contains the paren]Guillaume
>> Nodet ---06/30/2014 01:10:56 PM---This is the first release of a set. It
>> contains the parent pom in version 2.0.0
>>
>> From: Guillaume Nodet <gn...@apache.org>
>> To: dev@aries.apache.org
>> Date: 06/30/2014 01:10 PM
>> Subject: [VOTE] Release Apache Aries Parent 2.0.0
>> ------------------------------
>>
>>
>>
>> This is the first release of a set.
>> It contains the parent pom in version 2.0.0
>>
>> Staging repository available at
>> https://repository.apache.org/content/repositories/orgapachearies-1002
>>
>> [ ] +1 Release parent 2.0.0
>> [ ] -1 Do not
>>
>> Cheers,
>> Guillaume Nodet
>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com