dependency versioning design

[Mike Power <mp...@dodtsair.com>]

Has there been any thought to changing the design maven uses for 
versioning?  I often find that the versioning system is too constrictive 
and really does not fit well with the actual work flows of software 
development.

I was wondering if there was a general consensus that software 
development has exceeded the original design constraints of dependency 
versions and whether there was already a community of thought to 
identify a newer more modern solution?

Mike Power

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: dependency versioning design

[Ansgar Konermann <an...@googlemail.com>]

Could you be a bit more concrete, give a few examples where you feel
restricted, describe the workflow you'd like to implement... things like
that.

Regards,

Ansgar
Am 10.03.2012 18:43 schrieb "Mike Power" <mp...@dodtsair.com>:

> Has there been any thought to changing the design maven uses for
> versioning?  I often find that the versioning system is too constrictive
> and really does not fit well with the actual work flows of software
> development.
>
> I was wondering if there was a general consensus that software development
> has exceeded the original design constraints of dependency versions and
> whether there was already a community of thought to identify a newer more
> modern solution?
>
> Mike Power
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: dependency versioning design

[Wayne Fay <wa...@gmail.com>]

> 1) Annotating a release requires a code change and a rebuild.

This can be annoying. I know there has been some discussion about a
possible "turn this snapshot into a release without actually
rebuilding anything, just changing metadata" plugin on this list but
don't believe anyone has built it yet.

> 2) Accepting dependencies.  If my project depends on a SNAPSHOT I get
> their latest and greatest.  Which is great I like continually
> integrating with my dependencies because we find problems early and fix
> them cheaply.  The problem is that when I find out a dependency has
> broken my project I have to wait for them to fix it before my project is
> fixed.  Add a bunch a dependencies and continual integration feels more
> like continual breakage.  I want to be able to test their drops and if
> they pass use them.

Can this be rephrased as "I want to be able to use SNAPSHOTs because I
like the positive side effects when things work right but I don't want
to deal with the negative consequences of depending on SNAPSHOTs when
things don't work right"?

How would you change things to accommodate your contrasting needs? Do
you have specific thoughts about how this might work? I could see this
being addressed by simply asking your dependencies to "please release
more often" if they have the ability to do so. Perhaps they can relase
a more stable nightly or weekly snapshot which has some degree of
testing vs what you are currently consuming. I'm not sure how Maven
can help with this.

> 3) Transitive dependencies.  A good half of my build breakages do not
> come from my direct dependencies.  Instead their dependencies break.

This only happens when you depend on SNAPSHOTs.

> Without any change in my dependency, the transitive dependencies can
> change.  My project did not bring these dependencies in, so we have no

Yes, this is prone to happen with SNAPSHOTs.

I'm not sure how Maven can help with these problems. Do you have
specific thoughts about how this might work? I agree there is merit in
some of this.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: dependency versioning design

[Mike Power <mp...@dodtsair.com>]

Thanks Seth,

Branching a code base is one of the major work flows where the current 
version design creates a mess.

Other examples include

1) Annotating a release requires a code change and a rebuild.  Forcing a 
QA check on the binary forcing the implementation of a release candidate 
process.  The release candidate process basically means you are going to 
say something is a release before you know it is a release because you 
can't say something is a release after you know it is a release.

2) Accepting dependencies.  If my project depends on a SNAPSHOT I get 
their latest and greatest.  Which is great I like continually 
integrating with my dependencies because we find problems early and fix 
them cheaply.  The problem is that when I find out a dependency has 
broken my project I have to wait for them to fix it before my project is 
fixed.  Add a bunch a dependencies and continual integration feels more 
like continual breakage.  I want to be able to test their drops and if 
they pass use them.

3) Transitive dependencies.  A good half of my build breakages do not 
come from my direct dependencies.  Instead their dependencies break. 
Without any change in my dependency, the transitive dependencies can 
change.  My project did not bring these dependencies in, so we have no 
familiarity with them or with their developers.  Yet because of this 
mechanism we end up testing the integration of the transitive dependency 
before our dependency has tested the integration.  I want to let my 
dependency do the integration with new transitive dependencies.  When 
they are successful then I'll integrate with the both of them.

Mike Power

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: dependency versioning design

[Seth Call <se...@gmail.com>]

Mike, 

I'm with you fully.  

This thread is a suggestion I made based on tying versioning to concepts
within the SCM very tightly.

In short, I was trying to provide three types of versioning:

* I want the latest official build, *of a branch*, for a particular
dependency (say, master-SNAPSHOT, or trunk-SNAPSHOT). 
-- This is for when I don't want to check out the project, but I want to
track along latest

* I want a specific official build, *of a branch*, for a particular
dependency (say, master-234, where 234 is the build number)
-- This is for when I still don't want to check out the project, but I need
to pin the version.

* I want a local build of a dependency for a given branch *and no other
build from anywhere else* (master-local, which would be a version that
should/could only exist in your local repo and in no public repos)
-- This is for when you need to check out the dependency project and want to
fix a bug/add a feature on it, and while you are doing that work, you want
to force the dependency to resolve to your local version


This model is for internal development.  I don't have much issue with
traditional means of publishing artifacts (i.e, 1.4.26), but I do think this
model could be used without change for true publishing of artifacts.


By the way, I've got the exact versioning scheme working perfectly with Ivy,
and done such that the developer never has to touch their ivy.xml (i.e,
pom.xml) unless they want to 'pin' or change the branch of a dependency.

 There are reasons (described in that thread), as to why this is currently
hard in Maven.  
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tc5543110.html

But I definitely want to do this in Maven, too.

--
View this message in context: http://maven.40175.n5.nabble.com/dependency-versioning-design-tp5553348p5553502.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org