Make a release of Hamcrest 2.0.0.0 #65
Comments
|
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. |
|
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 notifications@github.com wrote:
|
|
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. |
|
@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 |
|
@sf105 Are you actively looking for other people to maintain the project or are you content with the current person? |
|
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 |
|
We weren't looking but perhaps we should be. S On 22 Sep 2014, at 11:22, Will May notifications@github.com wrote:
|
|
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. |
|
Has there been any progress towards a 1.4 release lately? |
|
@rkcpi The project seems to be stagnating/dormant. Perhaps the founders no longer have time to take care of it. |
|
Ok, well.. I'd be willing to help if there's anything I can help with. I'd hate to see this project die.. |
|
@EarthCitizen @rkcpi I am available for help too |
|
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. |
|
Some concrete suggestions from a part-time maintainer of another GitHub project
Good luck! |
|
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. |
|
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. |
|
I've raised a JIRA with SonaType to be able to publish Hamcrest JARs to Maven Central. |
|
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. |
|
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/)? |
|
We're going to track Java language versions in the major version On Tuesday, December 23, 2014, Cristiano Gavião notifications@github.com
|
|
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? |
|
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). |
|
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 ? |
|
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. |
|
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. |
|
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. |
|
@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.. |
|
If OSGI can handle four-part version numbers, then I feel this is descending into bike-shedding. |
|
@npryce, OSGi version is handled this way: |
|
@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 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. |
|
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? |
|
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. |
sf105
changed the title
|
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. |
npryce
changed the title
|
OK. Back to 2.0 |
|
What happened to 2.0, as against 2.1? |
|
I was thinking 2.1.0.0 is the first public release (eg version 1.0.0) of But if that's confusing let's go for 2.0.0.0. On Friday, December 26, 2014, Steve Freeman notifications@github.com
|
|
Depends on #86 |
sf105
changed the title
There have been a number of changes since
hamcrest-java-1.3was released in 2012 and, for people who use Hamcrest's binary releases, it would be good to get them into a public 1.4 release.There was some discussion on the mailing list back in 2013 about a Java Hamcrest 1.4 Release Plan, which suggested that #32 was the blocker for a release. However, discussion on that pull request now implies that a new release is unlikely.
A new release would be a great resolution for this, but it would also be good to have some expectation-setting, so users can decide whether waiting, making their own releases, or forking would be their best option for getting a current Hamcrest build, or if there's any way to help out.
The text was updated successfully, but these errors were encountered: