Bump dependency versions

[lptr]

Use case: I have two modules in my pride, B depends on A:1.0.12. I make a change in A, which is instantly visible inside the pride, but checked out independently, B will still depend on A:1.0.12. It would be nice if Pride could give a hand in this situation, and either:

• bump the dependency automatically, or
• show where the user needs to bump the dependency manually (and maybe check if they haven't).

This could be done in a new command, say, pride bump.

[lptr]

cc @gymora

[agazso]

I'd love this!

[lptr]

I thought about this, and it's a pretty complicated problem.

First of all, Pride won't be able to actually bump any dependencies. That would involve two things that are not available to Pride:

• find out where you store the dependency version number in the build, and change it -- it could be anywhere, directly in the build.gradle, wrapped in a project property supplied via gradle.properties, calculated via some arcane magic etc.
• find out how you want to depend on a new version -- you might depend on an explicit version of another module, but you could also depend on 11.+ -- what's the bumped version of that when 12.1-23-g434343 is introduced? It could be 12.1-23-g434343, or 12.1-+ or 12+ or whatever.

I think what Pride could do is to try to identify which projects in your pride depend on other projects that would not match the dependency version number.

Say, you have module A that depends on module B in your pride. Module B's version number is 2.1, and module A depends on version 1.+. Because they are in the same pride, the version numbers are ignored, and module A will happily use module B's local copy. However, when you try to build module A on your CI, it will still find an older version matching 1.+.

What Pride could do in this case is this:

$ pride check-versions
module "A" refers to "1.2" of module "B", but module "B"'s version number is "2.0-12-g342325", you need to bump

And then you have to dig and find what version number you need to change to fix the situation.

Would this be useful?

[lptr]

I'm not sure this can be determined quickly, but if that's possible, maybe this could be done every time you run a pride command, just to be on the safe side.

[agazso]

It would be helpful if the output would be structured and it would be
ordered from the independent modules to the most dependent modules. Then we
could write another tool that would make the actual bump based on
conventions.

On Mon, Sep 8, 2014 at 1:12 PM, Lóránt Pintér [email protected]
wrote:

I'm not sure this can be determined quickly, but if that's possible, maybe
this could be done every time you run a pride command, just to be on the
safe side.

—
Reply to this email directly or view it on GitHub
#83 (comment).

[lptr]

Can you come up with such a convention?

[agazso]

I'm thinking of a tool called autobump, that analyzes the output of pride,
and then make the actual bumps, by calling ./scripts/bump.sh with the new
version number.

If you want to make your project autobumpable, you are responsible for
providing a ./scripts/bump.sh.

On Mon, Sep 8, 2014 at 1:32 PM, Lóránt Pintér [email protected]
wrote:

Can you come up with such a convention?

—
Reply to this email directly or view it on GitHub
#83 (comment).

[lptr]

Sounds like a plan. I still need a specification from you for the output format you'd expect form Pride.

[agazso]

How about:

bump: module_A depends on module_B, change old_version to new_version

Or in regex:

(?\w+): (?\w+) depends on (?\w+), change
(?<old_version>\w+) to (?<new_version>\w+)

Where action equals bump

On Mon, Sep 8, 2014 at 3:39 PM, Lóránt Pintér [email protected]
wrote:

Sounds like a plan. I still need a specification from you for the output
format you'd expect form Pride.

—
Reply to this email directly or view it on GitHub
#83 (comment).

[lptr]

Here's how the output looks like:

WARN: Project "com.prezi.cet:boxfish-cet" requests version 3.+ of project "com.prezi.geometry:boxfish-geometry", but its current version (2.3-SNAPSHOT) does not fulfill that request

[lptr]

It would be lovely to hide the Gradle output in the beginning, but unfortunately, that's still impossible: #2.