Push tagged builds automatically

@stephenplusplus

It'd be really nice to make our doc builds and the maven push all automagical based on the tags we have in the git repository.

/cc @stephenplusplus : Maybe you can add more color on how we did this for node.

(This stems from the discussion on #51)

Unfortunately, I'm not too familiar with the workflow and practices of a Java developer. We're lucky with Node, because Travis gives us the behavior we're looking for out of the box with an npm deploy provider: (see our travis.yml). If we push a new tag to the repo, it automatically runs our release.sh script to build the docs before publishing to npm on its own.

Travis says the solution for projects that don't have a supported deploy provider is just using the after_success block. Only one configuration is possible (as far as I know), and it has already been written to push snapshot updates. To get it to do something on tagged releases should be possible as well, but it can only be one or the other.

However, since you can point after_success to a shell script, you can get away with doing more complicated things. This may not be a great idea, but in theory, the following should be possible:

Run your after_success script (say, on-push.sh on every push to master)
on-push would somehow check for the most recent released version
on-push would somehow check for the latest tag in your repo
on-push would use 3 & 4 to determine if you need to push a snapshot or push a release & build the docs

Sorry I couldn't be more help.

Let me add here what I wrote in a not-so-related pull request. When a tag is pushed to the repository the $TRAVIS_TAG is set to its value. In the after_success script this variable can be inspected to check whether we have to push a snapshot (e.g. tag v0.8.0-SNAPSHOT) or a release (e.g. tag v0.8.0).

Before depolying in maven we also need to update version numbers in all pom.xml files (and READMEs). I see two solutions here:

Doing it by hand (possibly using a script) before pushing the tag
Doing it in Travis after pushing the tag: that is, let Travis get the version from $TRAVIS_TAG, update all pom.xml and READMEs and pushe a commit with the updated files

The problem I see with approach 2 is that we will have a commit tagged with a newer version while maven's pom.xml and READMEs are still to the previous version as Travis commit arrives later (is triggered by the tag). Forcing the tag to move to the next commit is a no-no.

I like approach 2 because it rely solely on git tags to publish a new version but I do not like having version update commits after their corresponding tag. Sticking to a 1-like solution might be better with this respect. Any thoughts?

I also like approach 2 but let me make sure I understand it...
Can Travis be triggered just by pushing a tag (without code change)?
If so, can Travis do something like the following?

if release_tag:
release_version = version from release_tag
prev_version = version from pom.xml
set poms version to release version and trigger site & maven push (don't commit poms)
if prev_version <= release_version:
modify poms to release_version + 1 + "-SNAPSHOT" and commit

Yes Travis should be triggered even if you push only tags and what you write should be doable without too much pain. The problems I see here are:

In git you will have a commit tagged with a version while in the commit pom and READMEs are set to an older (snapshot) version
Consider the case you tag with release version 1.6.0, what's the next SNAPSHOT version? 1.6.1-SNAPSHOT or 1.7.0-SNAPSHOT? In either case, what if you then jump to release version (and tag) 2.0.0? You end up being in release 2.0.0 having no snapshots for it but you will have either 1.7.0-SNAPSHOT or 1.6.1-SNAPSHOT with no corresponding release version.

Yes, in case of release version 1.6.0 I would expect it to automatically move the SNAPSHOT version in the POM to 1.6.1-SNAPSHOT.

As long as the tag release is smaller than POM version, we don't change the POM in gitHub (just locally for the maven and site pushes).

I don't see the difference between the 1.6.0 case and the 2.0.0 case (so maybe I don't understand the question). It should be fine to have such a jump (POM would be set to 2.0.1-SNAPSHOT) and site/maven will be pushed with a 2.0.0 release.
Maven dependencies should be fine with not having 1.7.0-SNAPSHOT or a like and should pick the latest release (snapshot or not) that is <= 1.7.0-SNAPSHOT.

Another option to consider is pushing tags just with a release type indicator.
e.g. major_relase, minor_release, incremental_release and according to that we will modify
the pom to push artifcats to maven and generate a site as well as modifying the pom in gitHub.
Thoughts?

I vote for the first option (using a script to update the poms before pushing the tag) because of the first bullet point (the tagged version will have an outdated pom.xml). I think option 2 would be a bit confusing down the line, especially if anybody checks out the repository using that tag.

/cc @mziccard @dhermes @stephenplusplus -- just for thoughts....

Just out of curiosity... shouldn't this be a solved problem? Is there something going on that we overlooked? I feel like any real Java project should have already figured this out..........

@aozarov

@aozarov The problem with jumping to 2.0.0 is not after the jump but before it:
Imagine you release version 1.6.0. Then the POM is moved automatically to 1.6.1-SNAPSHOT and every push then triggers a maven deploy of 1.6.1-SNAPSHOT. If you then decide to jump to release 2.0.0 by pushing the corresponding tag you will end up having published 1.6.1-SNAPSHOT but no 1.6.1 release as well as 2.0.0 release but no 2.0.0-SNAPSHOT. This is not a big deal.

@jgeewax I browsed some real java projects and it's a huge mess, some do version changes by hand like in approach 1 (e.g. hibernate but they use gradle), others (e.g. Spring) have a build bot triggered from outside git (I think) that fetches the repo, moves to new version the POMs and pushes the changes as well as a version tag back to the repository, publishes the artifact and finally puts a new "development version" in the POMs and pushes to git.

@mziccard

@mziccard Yes, I understand but I also don't think it is a big deal (it should be totally fine to skip a release for a snapshot when a change is no longer minor or to have a release without prior snapshots).

What did you think about using major/minor/incremental tags instead of specifying the version (and automate the book-keeping)? We could always also support jump/reset to specific version if need to...

@ajkannan can you describe the confusion?

@jgeewax I also looked at guava and Guice and though they both seem to use gitHub releases/tags I didn't find any evidence of automation for it. They do automate javadoc & maven snapshots push in a similar way to what we already do (but they do not use maven site).

Maybe we can look at a non-Google project for guidance?

@aozarov

@aozarov You mean using just major/minor/incremental as tag name without any version information? While I understand your point, in git a tag must be unique so you can not use them as if they were actions. A tag is like a label you add to a commit to allow users to clone the repository for a specific version/bug fix/feature/etc.