Make a release of Hamcrest 2.0.0.0 about javahamcrest

[EarthCitizen]

I agree. Time for a new release 😄 Two years is long overdue!

Who is the owner of the project? I don't see any activity by a user named "hamcrest", so I assume the owner is active under another name?

It would be great if the project was converted to Maven too.

[sf105]

to be blunt, we thought we had someone to take over the project but they've been busy with other things. It's surprisingly difficult to find people who will follow through over the long term.

While the project should be available via a pom, what advantage would there be to converting the project itself to maven? Most of the people I work with are moving away.

S

On 21 Sep 2014, at 04:56, EarthCitizen [email protected] wrote:

I agree. Time for a new release Two years is long overdue!

Who is the owner of the project? I don't see any activity by a user named "hamcrest", so I assume the owner is active under another name?

It would be great if the project was converted to Maven too.

—
Reply to this email directly or view it on GitHub.

[EarthCitizen]

One advantage of Maven would be that keeping the dependency jars as part of the project would likely no longer be necessary. They would simply be downloaded by the IDE or command line tool. And when you need to upgrade on dependency versions, you just update the project's POM.

And I believe that the existing Ant build script could still be used ...or at least the parts that do anything "unusual" could be re-used and stay Ant. I am not so familiar with the build process in this project, but is the only "unusual" thing that the build does (outside of clean, compile, test, package jars) is the processing of the @factory annotations?

Maven is still by far the most used tool. Gradle will likely catch up to Maven and surpass it in popularity, but we are probably a couple of years away from that.

[EarthCitizen]

@josephw I like the way the JUnit team creates issues and labels them so that people can easily see what contributions need to be done for the next release

[wjam]

@sf105 Are you actively looking for other people to maintain the project or are you content with the current person?

[josephw]

In case anyone is interested in trying it out, I've made a release as 1.4-atlassian-1 to the Atlassian 3rdParty Repository (Atlassian Maven Repositories) from this fork.

It's current master with the necessary changes to build and deploy with Maven. My intention is to make a build available, rather than diverge from the main repo, so I'm interested in any way I can help get an official release out with the same changes.

[sf105]

We weren't looking but perhaps we should be.

S

On 22 Sep 2014, at 11:22, Will May [email protected] wrote:

@sf105 Are you actively looking for other people to maintain the project or are you content with the current person?

—
Reply to this email directly or view it on GitHub.

[EarthCitizen]

Has anyone considered asking the JUnit team to fork this and officially make it part of JUnit or an official module thereof? They already include it in their release, and this project seems as though it is struggling here. If it were part of JUnit, everyone here could still have the chance to be major contributors, but due to the location transition, could pick up additional visibility and resources.

I really like this project, I use it constantly, and I would like to see it be strong, grow and not slowly fade away.

[sandra-thieme]

Has there been any progress towards a 1.4 release lately?

[EarthCitizen]

@rkcpi The project seems to be stagnating/dormant. Perhaps the founders no longer have time to take care of it.

[sandra-thieme]

Ok, well.. I'd be willing to help if there's anything I can help with. I'd hate to see this project die..

[npathai]

@EarthCitizen @rkcpi I am available for help too

[kcooney]

Hey, guys. I'm a common contributor to JUnit. I don't think having JUnit contain a fork of Hamcrest world be best for Hamcrest users.

It sounds like the Hamcrest project is in a similar place as the JUnit project was a few years ago in terms of contributions from users and maintainers. If the Hamcrest team would like to contact us to discuss how we started to turn things around, feel free to reach out to me.

[kcooney]

Some concrete suggestions from a part-time maintainer of another GitHub project

• Create issues that are clear and limited. Moving to maven is a lot of effort, so I suggest considering not tying it to the release
• Most of the changes to JUnit come from people who are not regular maintainers. For smaller fixes, sending clean pull requests (with tests) helps.

Good luck!

[erizzo]

This particular issue is not about how to advance the development of Hamcrest (that's another problem that exists), but rather just to get a release of the current code base. AFAIK, no pull request is going to solve that problem, only a committer on the project can do a release.

[npryce]

In the past, development of Hamcrest has been upstream from packaging. Packaging projects have taken the built Hamcrest JARs and packaged them in various ways (RPMs, debs, Maven POM etc.).

The folks doing the Maven publishing have fallen out of touch. If we want publishing to Maven Central to be part of Hamcrest's build pipeline, we'll have to create that part from scratch.

I've found it easy to publish to Maven Central via Bintray -- publish to Bintray. Meanwhile raise JIRAs to sync Hamcrest's Bintray repo into Maven Central.

I've got build files to do that in another project that I can port over.

[npryce]

I've raised a JIRA with SonaType to be able to publish Hamcrest JARs to Maven Central.

[npryce]

The next release will be named 7.0 because it contains changes that are not backward compatible and will drop support for Java 6 and below now that Java 6 is EOL.

[cvgaviao]

humm, I couldn't understand the reason for moving from 1.3 to 7.0. why not use 2.0 then, which is more concise with a semantic versioning (http://semver.org/)?

[npryce]

We're going to track Java language versions in the major version
number. Hamcrest 8.x will be Java 8 and above, and rely on Java 8 function
and predicate types to integrate well with streams and collections.
Hamcrest 7.x relies on Java 7 language features (@SafeVarargs, "diamonds")

On Tuesday, December 23, 2014, Cristiano Gavião [email protected]
wrote:

humm, I couldn't understand the reason for moving from 1.3 to 7.0. why not
use 2.0 then, which is more concise with a semantic versioning (
http://semver.org/)?

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

[erizzo]

I'm excited to see progress on producing a new release, but I have to agree with cvgaviao that the numbering scheme doesn't make sense. Plenty of other projects release versions that require specific versions of Java but don't choose to couple their own versioning to Java's. Is there any precedent or justification for that coupling?
In the end I recognize that it's the Hamcrest developers' choice to make; I'm just providing community feedback that it doesn't make much sense from the outside.

[npryce]

I've found that semver doesn't work well for APIs and that Stream.Major.Minor.Patch works better, where Stream represents a "conceptually significant" change to the API and Major, Minor and Patch work just like semver. So, if we move Hamcrest to this model, the Java 7 stream would start at 7.1.0.0, bumping to 7.2.0.0 on a breaking API change. A release that support Java 8 only (dropping Java 7 support) would up the Stream number and so be 8.1.0.0.

Obviously, "conceptually significant" is subjective. I reserve it for changing the conceptual model of the API or deep changes to the language or APIs that the library depends on (switching the Matcher interface to extend Java 8 Predicate would, IMO, require an increment of the Stream number).

[cvgaviao]

Could you give me an example of API that doesn't work well with semver that you found ? And could you give me any example of a project using that Stream versioning ?
I used to work with hundreds of API in the OSGi world and the only few ones that I had problems was the ones that do not have increased its version properly following the established rules...
I have not sure yet, but I'm afraid that won't be possible to map your versioning model to osgi...

[npryce]

Take Apache projects (http://commons.apache.org/releases/versioning.html). They increment major versions for "significant changes to a component". But also for any interface breaking change. So major version increments are overloaded to have two meanings.

Jackson repackages all classes for major version increments (https://github.com/FasterXML/jackson-docs), so a small backward-incompatible change to an API that could be absorbed incrementally by clients must be released in an entirely different package structure, requiring large changes across client code.

I didn't know OSGI was so restrictive in its use of version numbers. Four-part version numbers are not uncommon -- quite a few packages on my Ubuntu system have four-part version numbers (not counting the packager's build number). So for OSGI the stream number would have to be in the bundle name. E.g. hamcrest-7 1.0.0 or hamcrest-8 1.0.0.

[erizzo]

My objection is not to a 4-segment version scheme, even OSGi/Eclipse uses that, they just call the segments MAJOR.MINOR.SERVICE.QUALIFIER and QUALIFIER can be non-numeric and usually has extra meaning such as a date or a Maven-esque description. That all seems to be compatible with what you want to do, roughly speaking.
My objection is tying Hamcrest (stream/MAJOR/wahtever-you-call-it) to Java versions. The coupling seems unnecessary.

[npryce]

Qualifier is different from normal numbers in that it "subtracts" from the version. In normal semver it's separated from the version number with a "-", not a ".". E.g. 1.0.0-RC1 is the first release candidate for 1.0.0 and so comes before 1.0.0.

[npryce]

@erizzo - we're going to maintain two versions for a while. One compatible with Java 7, one taking advantage of Java 8 language and runtime features. We think having the stream number reflect that communicates it better than 2 and 3..

[npryce]

If OSGI can handle four-part version numbers, then I feel this is descending into bike-shedding.

[cvgaviao]

@npryce, OSGi version is handled this way:
major - a breaking change
minor - a backward compatible changes
micro - a bug fix (no API change)
qualifier - a new build
But you want a number before the major. that is the reason I said that couldn't be fit OSGi versioning model.
http://www.aqute.biz/Bnd/Versioning

[erizzo]

@npryce Yes OSGi uses 4 segments but the qualifier is different than you might want. The classic problem is that 2.0.0.beta > 2.0.0 in the OSGi world, so your releases must have a qualifier that makes them greater-than whatever you used for pre-release builds. That's one of the reasons most Eclipse bundles use a datestamp in the qualifier, such as 1.2.3.20141223-something
Read more at http://eclipsesource.com/blogs/2013/06/28/semantic-versioning-for-eclipse-developers/

As a counter-example to what you're planning, look at what Apache commons has done when they introduced generics (Java 6) dependency - they upped the version of Commons Lang from 2.x to 3.x (similar for some other Commons libraries); they also changed their maven artifact IDs, which isn't strictly necessary and kind of bugs me. I don't think anyone is really confused about what version of Commons Lang they want, probably because most of the world long ago moved to (at least) Java 6. The situation around Java 8 is a little different, I agree, because Java 8 adoption is far from ubiquitous yet. But knowing Hamcrest 3 is Java 8 seems like something people would discover easily enough. Just my opinion, based on experience that tying version names together can sometimes get messy down the road.
I've said my piece, in the end it is your decision and we (the user community) will live with it.

[npryce]

Ok, I'm convinced. 2.1.0.0 for the next release, supporting Java 7 and above. 3.1.0.0 when we support Java 8 and above and redesign the API to integrate smoothly into the new Java 8 standard library.

@sf105 - is that ok by you?

[sf105]

I suggest java 7 -> 3.0, java 8 -> 4.0.

The reason is that we should probably also consider a back port of the new structure for Java 7-1, for Android.

[npryce]

I don't understand your reasoning. The new API should be 2.1.0.0. If we maintain a stream to support a subset of Java7 for Android that would be a different product -- hamcrest-android 2.1.0.0 for example. But I don't see much demand for running Hamcrest in production code on old Android devices. So, I think we should not worry about this until there is demand, and then work out a way of identifying those versions.

[sf105]

OK. Back to 2.0

[sf105]

What happened to 2.0, as against 2.1?

[npryce]

I was thinking 2.1.0.0 is the first public release (eg version 1.0.0) of
stream 2.

But if that's confusing let's go for 2.0.0.0.

On Friday, December 26, 2014, Steve Freeman [email protected]
wrote:

What happened to 2.0, as against 2.1?

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

[npryce]

Depends on #86