Re: Reproducibility versus ranges

[Stephen Connolly]

The idea I had in versions-m-p was to put XML PI with the original range
beside the resolved value so that the range can be set back post prepare
(see completionGoals)

Oh where is my elusive time

On Monday 26 October 2015, Bernd Eckenfels  wrote:

> Am Mon, 26 Oct 2015 13:03:03 -0400
> schrieb Benson Margulies >:
> > Do we have any tooling for this? In my imagination, the top pom for a
> > product to be released could be auto-decorated with
> > dependencyManagement locks.
>
> I think besides the release-with-pom from the release plugin but also
> versions:resolve-ranges:
>
> http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
>
> Gruss
> Bernd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

-- 
Sent from my phone

Re: Reproducibility versus ranges

[Fred Cooke]

Conflicting ranges should break the build, and would break it in the first
place. If it released OK in the first place with bounded ranges and your
repo still has the artifacts, it can be released again. If the old ranges
now won't release, you have a conflict to resolve in your tree.

On Tue, Oct 27, 2015 at 11:39 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Shoot me for not giving the full response.
>
> Release.properties is too hacky to contain all the info to be
> restored/restored with modifications.
>
> Never mind that if you lost the release.properties file and had to resume
> elsewhere you might get stuck.
>
> So in my view you need to stash the original range in the pom... XMLPI is
> the logical holder as it is a processing instruction for the release plugin
> (or versions plugin)
>
> You need to bump the lower limit to whatever the range got resolved to when
> switching back to development.
>
> The only remaining issue is how would people resolve conflicts of multiple
> dependencies all have conflicting hard ranges? (Ok you add excludes... But
> still could get hairy... Ok likely alerting of potential issue too there)
>
> On Monday 26 October 2015, Fred Cooke  wrote:
>
> > In our case, we don't want the original range back exactly, we want the
> > current version of that, ie, higher lower bound to currently released
> > things.
> >
> > Do not forget the transient ranges that need to be locked in our modified
> > pom, either. Without this any tooling would be severely limited in use.
> >
> > Fred.
> >
> > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com > wrote:
> >
> > > The idea I had in versions-m-p was to put XML PI with the original
> range
> > > beside the resolved value so that the range can be set back post
> prepare
> > > (see completionGoals)
> > >
> > > Oh where is my elusive time
> > >
> > > On Monday 26 October 2015, Bernd Eckenfels  > > wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies 
> > >:
> > > > > Do we have any tooling for this? In my imagination, the top pom
> for a
> > > > > product to be released could be auto-decorated with
> > > > > dependencyManagement locks.
> > > >
> > > > I think besides the release-with-pom from the release plugin but also
> > > > versions:resolve-ranges:
> > > >
> > > >
> http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >  
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > > 
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
>
> --
> Sent from my phone
>

Re: Reproducibility versus ranges

[Bernd Eckenfels]

Hello,

you dont need to remeber the ranges if you will not touch the ranged pom
on the trunk/master/devel branch, only the release
tags/commits/branches have that expanded version. (Just like the
version tag, its the only pom incarnation with a non-snapshot one).

Gruss
Bernd

Am Mon, 26 Oct 2015
22:39:14 + schrieb Stephen Connolly
:

> Shoot me for not giving the full response.
> 
> Release.properties is too hacky to contain all the info to be
> restored/restored with modifications.
> 
> Never mind that if you lost the release.properties file and had to
> resume elsewhere you might get stuck.
> 
> So in my view you need to stash the original range in the pom...
> XMLPI is the logical holder as it is a processing instruction for the
> release plugin (or versions plugin)
> 
> You need to bump the lower limit to whatever the range got resolved
> to when switching back to development.
> 
> The only remaining issue is how would people resolve conflicts of
> multiple dependencies all have conflicting hard ranges? (Ok you add
> excludes... But still could get hairy... Ok likely alerting of
> potential issue too there)
> 
> On Monday 26 October 2015, Fred Cooke  wrote:
> 
> > In our case, we don't want the original range back exactly, we want
> > the current version of that, ie, higher lower bound to currently
> > released things.
> >
> > Do not forget the transient ranges that need to be locked in our
> > modified pom, either. Without this any tooling would be severely
> > limited in use.
> >
> > Fred.
> >
> > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com > wrote:
> >
> > > The idea I had in versions-m-p was to put XML PI with the
> > > original range beside the resolved value so that the range can be
> > > set back post prepare (see completionGoals)
> > >
> > > Oh where is my elusive time
> > >
> > > On Monday 26 October 2015, Bernd Eckenfels  > > wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies 
> > >:
> > > > > Do we have any tooling for this? In my imagination, the top
> > > > > pom for a product to be released could be auto-decorated with
> > > > > dependencyManagement locks.
> > > >
> > > > I think besides the release-with-pom from the release plugin
> > > > but also versions:resolve-ranges:
> > > >
> > > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >  
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > > 
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reproducibility versus ranges

[Fred Cooke]

Ahh, but we do, everything is ranged! As explained, externals are ranged
via composites in between to isolate us from their whims, eg spring, etc.

On Tue, Oct 27, 2015 at 2:13 PM, Bernd Eckenfels 
wrote:

> If you do not release POMs with ranges there are no poms with ranges to
> depend on.
>
> Am Tue, 27 Oct 2015 14:03:01 +1300
> schrieb Fred Cooke :
>
> > False, you've locked to a specific version of a thing which depends on
> > ranges. This does not lock down those ranges, as it doesn't have
> > enough information to do that.
> >
> > On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels
> >  wrote:
> >
> > > Hello,
> > >
> > > if you lock down ranges on release your dependencies will also have
> > > no ranges and you do not need to lock them down transitively.
> > >
> > > BTW: I really think tis is a topic for the maven-user list.
> > >
> > > Gruss
> > > Bernd
> > >
> > >  Am Tue, 27
> > > Oct 2015 11:21:09 +1300 schrieb Fred Cooke :
> > >
> > > > In our case, we don't want the original range back exactly, we
> > > > want the current version of that, ie, higher lower bound to
> > > > currently released things.
> > > >
> > > > Do not forget the transient ranges that need to be locked in our
> > > > modified pom, either. Without this any tooling would be severely
> > > > limited in use.
> > > >
> > > > Fred.
> > > >
> > > > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > > > The idea I had in versions-m-p was to put XML PI with the
> > > > > original range beside the resolved value so that the range can
> > > > > be set back post prepare (see completionGoals)
> > > > >
> > > > > Oh where is my elusive time
> > > > >
> > > > > On Monday 26 October 2015, Bernd Eckenfels
> > > > >  wrote:
> > > > >
> > > > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > > > schrieb Benson Margulies  > > > > > >:
> > > > > > > Do we have any tooling for this? In my imagination, the top
> > > > > > > pom for a product to be released could be auto-decorated
> > > > > > > with dependencyManagement locks.
> > > > > >
> > > > > > I think besides the release-with-pom from the release plugin
> > > > > > but also versions:resolve-ranges:
> > > > > >
> > > > > >
> > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > > > >
> > > > > > Gruss
> > > > > > Bernd
> > > > > >
> > > > > >
> -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > >  For additional commands, e-mail:
> > > > > > dev-h...@maven.apache.org
> > > > > 
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Sent from my phone
> > > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Reproducibility versus ranges

[Fred Cooke]

In our case, we don't want the original range back exactly, we want the
current version of that, ie, higher lower bound to currently released
things.

Do not forget the transient ranges that need to be locked in our modified
pom, either. Without this any tooling would be severely limited in use.

Fred.

On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> The idea I had in versions-m-p was to put XML PI with the original range
> beside the resolved value so that the range can be set back post prepare
> (see completionGoals)
>
> Oh where is my elusive time
>
> On Monday 26 October 2015, Bernd Eckenfels  wrote:
>
> > Am Mon, 26 Oct 2015 13:03:03 -0400
> > schrieb Benson Margulies >:
> > > Do we have any tooling for this? In my imagination, the top pom for a
> > > product to be released could be auto-decorated with
> > > dependencyManagement locks.
> >
> > I think besides the release-with-pom from the release plugin but also
> > versions:resolve-ranges:
> >
> > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> >
> > Gruss
> > Bernd
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> >
> >
>
> --
> Sent from my phone
>

Re: Reproducibility versus ranges

[Fred Cooke]

False, you've locked to a specific version of a thing which depends on
ranges. This does not lock down those ranges, as it doesn't have enough
information to do that.

On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels 
wrote:

> Hello,
>
> if you lock down ranges on release your dependencies will also have no
> ranges and you do not need to lock them down transitively.
>
> BTW: I really think tis is a topic for the maven-user list.
>
> Gruss
> Bernd
>
>  Am Tue, 27
> Oct 2015 11:21:09 +1300 schrieb Fred Cooke :
>
> > In our case, we don't want the original range back exactly, we want
> > the current version of that, ie, higher lower bound to currently
> > released things.
> >
> > Do not forget the transient ranges that need to be locked in our
> > modified pom, either. Without this any tooling would be severely
> > limited in use.
> >
> > Fred.
> >
> > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > The idea I had in versions-m-p was to put XML PI with the original
> > > range beside the resolved value so that the range can be set back
> > > post prepare (see completionGoals)
> > >
> > > Oh where is my elusive time
> > >
> > > On Monday 26 October 2015, Bernd Eckenfels 
> > > wrote:
> > >
> > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > schrieb Benson Margulies >:
> > > > > Do we have any tooling for this? In my imagination, the top pom
> > > > > for a product to be released could be auto-decorated with
> > > > > dependencyManagement locks.
> > > >
> > > > I think besides the release-with-pom from the release plugin but
> > > > also versions:resolve-ranges:
> > > >
> > > >
> http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > >
> > > > Gruss
> > > > Bernd
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >  For additional commands, e-mail:
> > > > dev-h...@maven.apache.org
> > > 
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Reproducibility versus ranges

[Bernd Eckenfels]

Hello,

if you lock down ranges on release your dependencies will also have no
ranges and you do not need to lock them down transitively.

BTW: I really think tis is a topic for the maven-user list.

Gruss
Bernd

 Am Tue, 27
Oct 2015 11:21:09 +1300 schrieb Fred Cooke :

> In our case, we don't want the original range back exactly, we want
> the current version of that, ie, higher lower bound to currently
> released things.
> 
> Do not forget the transient ranges that need to be locked in our
> modified pom, either. Without this any tooling would be severely
> limited in use.
> 
> Fred.
> 
> On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
> > The idea I had in versions-m-p was to put XML PI with the original
> > range beside the resolved value so that the range can be set back
> > post prepare (see completionGoals)
> >
> > Oh where is my elusive time
> >
> > On Monday 26 October 2015, Bernd Eckenfels 
> > wrote:
> >
> > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > schrieb Benson Margulies >:
> > > > Do we have any tooling for this? In my imagination, the top pom
> > > > for a product to be released could be auto-decorated with
> > > > dependencyManagement locks.
> > >
> > > I think besides the release-with-pom from the release plugin but
> > > also versions:resolve-ranges:
> > >
> > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > >
> > > Gruss
> > > Bernd
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >  For additional commands, e-mail:
> > > dev-h...@maven.apache.org
> > 
> > >
> > >
> >
> > --
> > Sent from my phone
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reproducibility versus ranges

[Stephen Connolly]

Shoot me for not giving the full response.

Release.properties is too hacky to contain all the info to be
restored/restored with modifications.

Never mind that if you lost the release.properties file and had to resume
elsewhere you might get stuck.

So in my view you need to stash the original range in the pom... XMLPI is
the logical holder as it is a processing instruction for the release plugin
(or versions plugin)

You need to bump the lower limit to whatever the range got resolved to when
switching back to development.

The only remaining issue is how would people resolve conflicts of multiple
dependencies all have conflicting hard ranges? (Ok you add excludes... But
still could get hairy... Ok likely alerting of potential issue too there)

On Monday 26 October 2015, Fred Cooke  wrote:

> In our case, we don't want the original range back exactly, we want the
> current version of that, ie, higher lower bound to currently released
> things.
>
> Do not forget the transient ranges that need to be locked in our modified
> pom, either. Without this any tooling would be severely limited in use.
>
> Fred.
>
> On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com > wrote:
>
> > The idea I had in versions-m-p was to put XML PI with the original range
> > beside the resolved value so that the range can be set back post prepare
> > (see completionGoals)
> >
> > Oh where is my elusive time
> >
> > On Monday 26 October 2015, Bernd Eckenfels  > wrote:
> >
> > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > schrieb Benson Margulies 
> >:
> > > > Do we have any tooling for this? In my imagination, the top pom for a
> > > > product to be released could be auto-decorated with
> > > > dependencyManagement locks.
> > >
> > > I think besides the release-with-pom from the release plugin but also
> > > versions:resolve-ranges:
> > >
> > > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > >
> > > Gruss
> > > Bernd
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>  
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> > 
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>


-- 
Sent from my phone

Re: Reproducibility versus ranges

[Bernd Eckenfels]

If you do not release POMs with ranges there are no poms with ranges to
depend on.

Am Tue, 27 Oct 2015 14:03:01 +1300
schrieb Fred Cooke :

> False, you've locked to a specific version of a thing which depends on
> ranges. This does not lock down those ranges, as it doesn't have
> enough information to do that.
> 
> On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels
>  wrote:
> 
> > Hello,
> >
> > if you lock down ranges on release your dependencies will also have
> > no ranges and you do not need to lock them down transitively.
> >
> > BTW: I really think tis is a topic for the maven-user list.
> >
> > Gruss
> > Bernd
> >
> >  Am Tue, 27
> > Oct 2015 11:21:09 +1300 schrieb Fred Cooke :
> >
> > > In our case, we don't want the original range back exactly, we
> > > want the current version of that, ie, higher lower bound to
> > > currently released things.
> > >
> > > Do not forget the transient ranges that need to be locked in our
> > > modified pom, either. Without this any tooling would be severely
> > > limited in use.
> > >
> > > Fred.
> > >
> > > On Tue, Oct 27, 2015 at 11:02 AM, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > The idea I had in versions-m-p was to put XML PI with the
> > > > original range beside the resolved value so that the range can
> > > > be set back post prepare (see completionGoals)
> > > >
> > > > Oh where is my elusive time
> > > >
> > > > On Monday 26 October 2015, Bernd Eckenfels
> > > >  wrote:
> > > >
> > > > > Am Mon, 26 Oct 2015 13:03:03 -0400
> > > > > schrieb Benson Margulies  > > > > >:
> > > > > > Do we have any tooling for this? In my imagination, the top
> > > > > > pom for a product to be released could be auto-decorated
> > > > > > with dependencyManagement locks.
> > > > >
> > > > > I think besides the release-with-pom from the release plugin
> > > > > but also versions:resolve-ranges:
> > > > >
> > > > >
> > http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html
> > > > >
> > > > > Gruss
> > > > > Bernd
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > >  For additional commands, e-mail:
> > > > > dev-h...@maven.apache.org
> > > > 
> > > > >
> > > > >
> > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reproducibility versus ranges

[Anders Hammar]

You're right, this is the problem. What would need to be done is the
version to be fixed for the release version (tag).

/Anders (mobile)
Den 26 okt 2015 15:55 skrev "Benson Margulies" :

> Folks,
>
> I would appreciate some assistance in thinking through the
> implications of the use of version ranges.
>
> As a thought experiment, consider a loosely-coupled collection of
> maven project, maintained with a semver discipline.
>
> Each component has dependencies, and those are written with ordinary
> dependency elements. No dependency management, no ranges.
>
> Maven will resolve version numbers, and the builds will be 100%
> reproducible. However, the resolution algorithm is not semver, it's
> doing the tree distance thing.
>
> So, to get semver semantics, I might consider adding ranges. However,
> and here I hope I'm confused, I just lost reproducibility. If someone
> adds a new version to the repository, a re-run of the build will
> select it if it satisfies the ranges. Rebuilding from the tag is not
> the same build.
>
> Am I missing something? Could it be that the release process somehow
> resolves the ranges and writes them into the poms?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Reproducibility versus ranges

[Bernd Eckenfels]

Am Mon, 26 Oct 2015 13:03:03 -0400
schrieb Benson Margulies :
> Do we have any tooling for this? In my imagination, the top pom for a
> product to be released could be auto-decorated with
> dependencyManagement locks.

I think besides the release-with-pom from the release plugin but also
versions:resolve-ranges:

http://www.mojohaus.org/versions-maven-plugin/resolve-ranges-mojo.html

Gruss
Bernd

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reproducibility versus ranges

[Fred Cooke]

There is a plugin by a friend of a friend (don't ask me what it's called)
that writes out a de-ranged pom.xml as part of the build, in the event that
you need to reproduce a build, eg, branching from a tag for a production
fix, you swap in the tag, drop in the pom, make the change down stream as
required, depend on it with [], and continue. We use ranges here for the
entire tree. External deps are isolated through compositions with fixed []
deps and they themselves are ranged (because we control them). It does
require "semver discipline", however it makes for predictable and fluid
development forward. Do note that you need to de-range transitively for
this to work, ie, transitively resolved artefacts must be in the new fixed
pom.

On Tue, Oct 27, 2015 at 6:03 AM, Benson Margulies 
wrote:

> On Mon, Oct 26, 2015 at 11:42 AM, Anders Hammar
>  wrote:
> > You're right, this is the problem. What would need to be done is the
> > version to be fixed for the release version (tag).
>
> Do we have any tooling for this? In my imagination, the top pom for a
> product to be released could be auto-decorated with
> dependencyManagement locks.
>
> >
> > /Anders (mobile)
> > Den 26 okt 2015 15:55 skrev "Benson Margulies" :
> >
> >> Folks,
> >>
> >> I would appreciate some assistance in thinking through the
> >> implications of the use of version ranges.
> >>
> >> As a thought experiment, consider a loosely-coupled collection of
> >> maven project, maintained with a semver discipline.
> >>
> >> Each component has dependencies, and those are written with ordinary
> >> dependency elements. No dependency management, no ranges.
> >>
> >> Maven will resolve version numbers, and the builds will be 100%
> >> reproducible. However, the resolution algorithm is not semver, it's
> >> doing the tree distance thing.
> >>
> >> So, to get semver semantics, I might consider adding ranges. However,
> >> and here I hope I'm confused, I just lost reproducibility. If someone
> >> adds a new version to the repository, a re-run of the build will
> >> select it if it satisfies the ranges. Rebuilding from the tag is not
> >> the same build.
> >>
> >> Am I missing something? Could it be that the release process somehow
> >> resolves the ranges and writes them into the poms?
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Reproducibility versus ranges

[Christian Schulte]

Am 26.10.2015 um 15:54 schrieb Benson Margulies:

Am I missing something? Could it be that the release process somehow
resolves the ranges and writes them into the poms?


This is what 'mvn release:prepare-with-pom' would do.

Regards,
--
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Reproducibility versus ranges

[Benson Margulies]

On Mon, Oct 26, 2015 at 11:42 AM, Anders Hammar
 wrote:
> You're right, this is the problem. What would need to be done is the
> version to be fixed for the release version (tag).

Do we have any tooling for this? In my imagination, the top pom for a
product to be released could be auto-decorated with
dependencyManagement locks.

>
> /Anders (mobile)
> Den 26 okt 2015 15:55 skrev "Benson Margulies" :
>
>> Folks,
>>
>> I would appreciate some assistance in thinking through the
>> implications of the use of version ranges.
>>
>> As a thought experiment, consider a loosely-coupled collection of
>> maven project, maintained with a semver discipline.
>>
>> Each component has dependencies, and those are written with ordinary
>> dependency elements. No dependency management, no ranges.
>>
>> Maven will resolve version numbers, and the builds will be 100%
>> reproducible. However, the resolution algorithm is not semver, it's
>> doing the tree distance thing.
>>
>> So, to get semver semantics, I might consider adding ranges. However,
>> and here I hope I'm confused, I just lost reproducibility. If someone
>> adds a new version to the repository, a re-run of the build will
>> select it if it satisfies the ranges. Rebuilding from the tag is not
>> the same build.
>>
>> Am I missing something? Could it be that the release process somehow
>> resolves the ranges and writes them into the poms?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org