Release Tags?

[ooxi]

The most up to date release seams to be 0.26 (according to maven central) which is not reflected in the README.md. Moreover a couple of release tags seam to be missing.

[cgruber]

I can update the readme, but we missed some release tags, becaue we had some abortive releases. I'm not sure we can replicate at this point, but we're trying to tag reliably forward.

[nresare]

It would certainly be possible to tag earlier revisions to make the mapping between maven central artefacts and source code less opaque. For example, when looking around a bit in the source code it seems version 0.23 (significant because it's a dependency of the lastest stable release of guava) corresponds to 3c4492b0f72 so if someone with push rights to the repository would issue the following commands on a local copy:

git tag release_0_23 3c4492b0f72
git push --tags

That would resolve one of the missing tags of a version of the library that is in widespread use.

The reason I'm interested in this is because I'm packaging this piece of software for the Fedora Linux distribution and it is useful to the project (and to reviewers of my packaging) to be able to ascertain that the revision that I package is indeed the release revision.

[cgruber]

I'm aware of git tags usage. Thank you. However, there may be specific release points where the tags weren't pushed, and which weren't merged into the code-line. If that's the case, then the specific commits are lost to git garbage collection, so we cannot discover the specific commits in order to tag them. The contents of the library are never different, but I'm loath to tag a release from a commit that is different than its value.

I suppose I could build the artifacts across a range of commits that are near to the release and see what commits result in identical results (the .asc and md5/sha hashes line up).

As of 0.27, all future versions will be rigorously tagged. Do you truly need this rigor in the past tense?

[nresare]

Sorry about that (the git tag details). Tracking down the specific revision that resulted in the 0.23 maven central artefacts is not a requirement but rather a nice to have. Hopefully we will have a new stable release of guava soon enough and we can all move on to the new nicer truth syntax.

[cgruber]

I'm confused - why do you need a newer Guava to use the newer truth syntax? Truth currently uses Guava 18, which is released. What am I missing?

[nresare]

It is perfectly reasonable to be confused, as what I left out some significant parts of the story. For completeness, it goes like this: Normal people use maven out of the box, and get builds with thousands of maven central hosted dependencies conveniently available. However, using binary third party dependencies of somewhat unclear origin is not how most linux distributions, such as Fedora, roll. We want to have source available in a standardised way, for a variety of reasons. Because of this, Fedora has spent considerable effort replicating a set of base maven dependencies from source so that maven projects (that depend only on software included in the distribution) can be built without downloading binary artefacts from maven central. That way, it is possible to ship java software in the distribution and build that software using maven but without depending on binary mystery jars.

One of the things we want to do to improve Fedora is to introduce truth into the distribution. Sounds good, doesn't it? The primary reason for this is that we want to build and include guava-testlib and run the guava unit tests. The version of guava currently shipping in fedora is 18.0, which means that we will package truth 0.23. This has the side effect of users the Fedora distribution, should they choose to use the project specific rebuild of maven artefacts (Invoked by using xmvn --offline instead of mvn when building, and having the proper dependencies installed as rpm packages) to be stuck on truth-0.23 until a guava version which depends on a later truth gets introduced.

As a side note about 3c4492b0f72 being a likely candidate for 0.23, I realised that maven central holds -source.jar files as well for most of it's releases as well as .pom and binary jars. Comparing the contents of the -source.jar and the pom turns out to match perfectly :)

[nresare]

To make it crystal clear, users of the Fedora linux distribution are of course free to use mvn to build their java projects. That way, all versions of truth that are available from maven central are available to them.

[cgruber]

Ahh. Ok. So.

(a) we plan on yanking the truth dependency out of guava-testlib, because it's not strictly necessary, and introduces an awkward dependency cycle we don't like.

(b) as a courtesy, I'll try to tag the missing release tags (thank you for vetting 0.23)

(c) I'm not sure on why you can't use 0.27 of Truth with Guava 18.0... are there inconsistencies that we have screwed up?

(d) what are the timelines for fedora inclusion of guava and truth, as we're talking about guava 19.0 release timelines now.

[PhilippWendler]

I am not the original poster, but I can nevertheless answer (c).

Indeed Guava-Testlib 18.0 breaks when upgrading to Truth 0.27, with the following exception:

java.lang.NoSuchMethodError: com.google.common.truth.Truth.assertThat(Ljava/util/Collection;)Lcom/google/common/truth/CollectionSubject;
  at com.google.common.collect.testing.testers.SortedMapNavigationTester.testTailMap(SortedMapNavigationTester.java:130)

The same error exists for testHeadMap and testSubMap, too. It is the reason why we could not upgrade Truth yet. I was assuming that this is known and will be fixed by a new release of Guava.

This at least also happens with Truth 0.26, but still works with 0.24.

[cgruber]

Ok. I definitely see the problem. I am sort of returning to a bit more focus on Truth, so thanks for letting me get caught up.

The problem is in the fact that we made Guava testlibs incorporate truth as a library dependency and we really screwed up there. Truth did not have the 1.0 level stability we should have required before making use of it in an intermediary library. I'm exploring short-term fixes to that related to Guava 18, but we will also remove the dependency on Truth in Guava 19.0. That latter is certain and in the plan.

Additionally, we're narrowing in on a 1.0 of Truth that will permit us to make more rigorous guarantees, having reviewed the method names and approaches strongly enough that we feel we can push any breaking changes to a 2.0, or live with names/signatures in perpetuity, to prevent this sort of issue in the future.

[cgruber]

I've noted this in google/guava#2073

[nresare]

Getting rid of the circular dependency between truth and guava would be welcome from my perspective as upgrading more than one package atomically is a bit of work. This would only be a problem if guava next depends on a truth version that also depends on new functionality in guava next, but when that happens there needs to be a bit of manual intervention in packaging land.

With regards to release timelines, the guava base library is already in Fedora 22 (which was released in late May) The Fedora 23 branch point will happen in mid July and our current plan is to include guava-testlib-18.0 and truth-0.23 into that. If there would be a new stable release of guava before that, possibly depending on a more recent truth, or not depending on truth at all I would be happy to put in the work to package it for inclusion.

[cgruber]

Truth was removed from Guava-Testlib in google/guava@e9a23fe#diff-463dba28b5028eb2265cb210f8cf72ef

As of Guava 19, truth is a test-only dependency of the guava-testlib-19.0 artifact, and should not, therefore, be added to the transitive dependency graph of any dependent.