Halyard 3.2 ("Senohraby")

Halyard 2.5 ("Prague") release supports legacy HBase 1.x clusters, while Halyard 3.2 ("Senohraby") release is targeted to support the newest HBase 2.x systems (including Hadoop 3 distributions).
Both releases are bringing the same improvements and bug-fixes.
The only major change is update of the underlying Eclipse RDF4J framework from version 2.5.1 to version 3.0.3. For the impact on Halyard check Eclipse RDF4J release notes.

Halyard 2.5 ("Prague")

Halyard 2.5 ("Prague") release supports legacy HBase 1.x clusters, while Halyard 3.2 ("Senohraby") release is targeted to support the newest HBase 2.x systems (including Hadoop 3 distributions).
Both releases are bringing the same improvements and bug-fixes.
The only major change is update of the underlying Eclipse RDF4J framework from version 2.5.1 to version 3.0.3. For the impact on Halyard check Eclipse RDF4J release notes.

Halyard 3.1 ("Fächerstadt")

Halyard 2.4 ("Karlsruhe") release supports legacy HBase 1.x clusters, while Halyard 3.1 ("Fächerstadt") release is targeted to support the newest HBase 2.x systems (including Hadoop 3 distributions).
Both releases are bringing the same improvements and bug-fixes.
Majority of the never-ending work has been done on the HalyardQueryJoinOptimizer and its cooperation with halyard:search and halyard:forkAndFilterBy features.
Unfortunately some of the promising improvements failed and had to be reverted due to negative effects.
Multiple issues have been fixed on Halyard Strategy, HBase Sail, and Halyard Endpoint components.

Halyard 2.4 ("Karlsruhe")

Halyard 2.4 ("Karlsruhe") release supports legacy HBase 1.x clusters, while Halyard 3.1 ("Fächerstadt") release is targeted to support the newest HBase 2.x systems (including Hadoop 3 distributions).
Both releases are bringing the same improvements and bug-fixes.
Majority of the never-ending work has been done on the HalyardQueryJoinOptimizer and its cooperation with halyard:search and halyard:forkAndFilterBy features.
Unfortunately some of the promising improvements failed and had to be reverted due to negative effects.
Multiple issues have been fixed on Halyard Strategy, HBase Sail, and Halyard Endpoint components.

Halyard 3.0 ("Piran")

Halyard 3.0 release is a part of double-release together with Halyard 2.3.
Purpose of version 3.0 release is to support the newest HBase 2.x systems (including Hadoop 3 distributions), while release 2.3 is targeted to the legacy HBase 1.x clusters.
Main new feature (beside the HBase 2 support) is new central HBaseRepositoryManager for RDF4J Server, which allows to spawn a battery of RDF4J Servers across the cluster and manage their repositories configuration centrally.
Important is also upgrade of RDF4J to version 2.5.1, and several minor fixes of Halyard Endpoint and Halyard Bulk Update tools.

Halyard 2.3 ("Portoroz")

Halyard 2.3 release is a part of double-release together with Halyard 3.0.
Purpose of version 2.3 release is to continue support of legacy HBase 1.x systems, while release 3.0 is targeted to the latest HBase 2.x clusters.
Main new feature is new central HBaseRepositoryManager for RDF4J Server, which allows to spawn a battery of RDF4J Servers across the cluster and manage their repositories configuration centrally.
Important is also upgrade of RDF4J to version 2.5.1, and several minor fixes of Halyard Endpoint and Halyard Bulk Update tools.

Halyard 2.2 ("Philadelphia")

Halyard 2.2 release brings several new tools, improvements and bugfixes.
One of the newly introduced tools is Halyard Endpoint, which may help you to instantly setup a read-only SPARQL endpoint from command line on any of your cluster node, with optional custom API configuration that translates into pre-configured SPARQL query calls.
Another new experimental MapReduce tool is is Halyard Summary, it calculates RDF summary of a dataset in a form of self-described synthetic RDF schema with cardinality attributes. Halyard Summary does not have yet any fancy peer UI application to present the summary, however even raw summary data might be helpful in certain situations.
From the various improvements and bugfixes I would highlight RDF4J updated to version 2.4.1, improvements in ElasticSearch Indexer, fixes in bindings handling in Halyard Federated Queries, better handling of namespaces during Bulk Load, fixed handling of Sesame.NIL constant according to the RDF4J standard, and several fixes in documentation.

nightly_build_20190102

fixed #50 Unclear how to use stats with named graphs - improve docs

Halyard 2.1 ("Heathrow")

Halyard 2.1 is mainly bug-fixing release with many new tests added.
There are several important fixes in Halyard Strategy, in SPARQL Optimizers, Cardinality Calculator, and bundled RDF4J Workbench.
Major focus was to enable smooth run of Halyard Federated Queries, complex Bulk Export and Bulk Update queries, and queries combining SPARQL with ElasticSearch support.
Last but not least - Halyard ElasticSearch Indexer has new feature to restrict indexation to just one specified named graph.

Halyard 2.0 ("Main Station")

Major focus of Halyard 2.0 release is on usability.
All the Halyard command line tools have been consolidated under one launcher and almost all of them have been improved. New SPARQL function halyard:forkAndFilterBy is unifying parallelization approach of Halyard Bulk Update and Bulk Export tools. Halyard ElasticSearch integration newly propagates results back to the SPARQL query variables and Halyard ElasticSearch Indexer allows to create the index mapping. Parsing of partially corrupted or invalid Turtle files is now more robust to Bulk Load maximum data also from "dirty" datasets (in --skip-invalid mode). Performance of the Halyard-internal SPARQL federation has been improved by including federated cardinalities in the query optimisation. And last but not least - new Halyard command line profiler tool reports SPARQL query optimizers data to help further offline performance analysis.