> How does this work with Ant? If you call publish_major the jar is
> build with another target publish_major depends on. The jar target
> does not know that publish major is called. So I guess the jar has no
> version name and but is published with a version name.
The jar does not have a version name (because ivy expects it to be without
before publishing), however, the manifest of the jar needs the version
number, thus it is like:
<target name="publish-minor"
depends="init,incr-version-minor,get-version,build">
<ivy-publish .../>
<antcall target="incr-version-patch"/> <!-- need to make sure that
next version is higher -->
</target>
We read/write the version from/to a property file and rely on the fact that
incr-version-minor and get-version (put version into property) is executed
before build - only the publishing is 100+ lines in a import file.
> I'm not sure if properties are the best way of doing this. I'd rather
> have the tasks publishMajor, publishMinor, publishPatch.
I would also think that tasks are better: you could easier start it from a
IDE-Integration like for ant, where you just doubleclick on a target. For
the command line it would not matter too much, if it is
- gradle -Dminor uploadLibs
or
- gradle publishMinor
Still the latter is clearer. But in this case we should think about the
naming - currently uploadLibs does the publishing...
> What would make the current version a snapshot version?
If we just want to do another build of a module during development, we add
-SNAPSHOT to the version number and we have
"mycompany:othermodule:latest.integration" as dependency. I would have
x.y.z-SNAPSHOT until the next patch or version is finished and then have a
x.y.z (or x.y+1.0, ...).
However, ivy (sometimes?) believes x.y.z-SNAPSHOT to be higher than x.y.z,
thus the next patch version is x.y.z+1.
The snapshot needs to be published, too, for other projects to use.
Of course an alternative strategy would be a build number...
> I think not necessarily the patch number. In our Gradle build we
> check if the working copy belong to trunk or a release branch. If it
> belong to trunk we increment the minor version, otherwise patch.
I think, there could be multiple built-in strategies in gradle (with one
being the default) and there should be an easy way to set the desired
strategy with a convention object property like
- versionStrategy = 'major-minor-patch-snapshot'
> 1.) Out-of-the-box + configuration (e.g. by properties)
> 2.) Out-of-the-box + hooked in custom strategies + configuration
> 3.) Toolbox usage. The custom logic does not fit into the framework
> but we can still support our users by providing tools (e.g.
> RepositoryVersionFinder.latestVersionFromRepository()).
Sounds good.
The option 3) should definitely be available to allow the user to implement
his (simple) strategy within the gradle.build file instead of implementing a
strategy, building a jar and deploying it to all developer gradle
installations.
--
View this message in context:
http://www.nabble.com/Version-numbers-tp20112226p20183073.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
