SNAPSHOT builds should be handeled as part of the version parameter, not the release parameter.

[helaar]

release parameter is more likely to be used by CI-server to reflect actual build or commit, than the date of build.

[helaar]

Suggests that the ${project.version} (i.e. 1.0-SNAPSHOT) is converted to a rpm compatible version number by replacing all dashes with a dot (i.e. 1.0.SNAPSHOT)

[dantran]

@helaar. the covertion to timestamp for snapshot build internally works out very well for me. with this behavior/feature my ci server is very dummy

[helaar]

Seems that I have to rephrase this issue. The original suggestion was wery tight coupeled to a problem I had on a multi module project, and we have now realized that the SNAPSHOT indicator should be a part of the release tag.

Still I do have problem declaring a dependency to an other artifact built by the same mother pom. I cannot use the rpm-maven-plugin:version goal as the other artifact is built from a different rpm-builder tool to build it.

I think an acceptable solution to this would be a parameter to turn off the timestamping mechanism and to combine any incoming rpm.release parameters with the snapshot indicator in a way where the version 1.0-SNAPSHOT is transformed to 1.0-${rpm.release}.SNAPSHOT

[liggetm]

I 2nd this request - the handling of the release parameter is inflexible (though I do appreciate why it is the way it is). Although the timestamps work well for individual developers, our process requires slurping *SNAPSHOT.rpm releases into an automated test harness. (We embed build information in the RPM description so the testing can be matched against an SCM ID).
It would be great if we could toggle the timestamp - currently we execute a shell script using the exec-maven-plugin plugin to do this after the RPM is built.

[bokken]

The rpm version semantics are very important here in determining what can be upgraded and what cannot. The desire of the plugin is to produce SNAPSHOT rpms which can be upgraded both to subsequent SNAPSHOT builds and to the released version. For example 1.0-SNAPSHOT can be upgraded to 1.0-1.

Are you proposing that you either do not care about this behavior or want to manage the release value (for both snapshot and release builds) manually to produce versions which upgrade?

On a separate topic, what type of dependency are you trying to declare? I first assumed maven, which did not make sense to me, as maven does not care about the rpm version semantics. Are you trying to declare rpm dependencies (i.e. requires) on specific versions of SNAPSHOT rpms?

[helaar]

@bokken my experience with yum is that 1.0-SNAPSHOT cannot be upgraded to 1.0-1. It is considered a newer version.

I'm trying to setup a Requires: depencency in the spec-file. The multi module maven project will build a main application rpm, and separate rpms holding environment configuration values for dirfferent einvironments (test/stage/prod). The environment values rpm should depend upon the application rpm of exact same version.

[bokken]

Using the version goal[1] should allow you to coordinate the same SNAPSHOT build version across a multi-module build.

This documentation[2] on rpm versions explicitly states that numbers are considered newer than letters. If yum is not treating 1.0-1 as newer than 1.0-SNAPSHOT, that would appear to be a defect with yum.

[1] - http://www.mojohaus.org/rpm-maven-plugin/version-mojo.html
[2] - https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison?rd=Tools/RPM/VersionComparison

[dantran]

@bokken do you have config sample how to get all RPM in a reactor using the same generated SNAPSHOT?

[borlafu]

@bokken my experience with yum is that 1.0-SNAPSHOT cannot be upgraded to 1.0-1. It is considered a newer version.

[borlafu@rpm-builder]# rpmdev-vercmp 1.0-SNAPSHOT 1.0-1
1.0-SNAPSHOT < 1.0-1