Disclaimer: Early access releases like this one are for development and experimentation only as not all features are in their finalized form. Click here if you’re looking for the latest stable version of Neo4j (3.1.0).
We are excited to kick-off the Neo4j 3.2 release cycle. Our plan is to have the final version ready in the first half of 2017.
Introducing Alpha and Beta
You may have noticed that our first packaged release in 3.2 train is not called Milestone anymore. Why is that? Well, we took a look at our software release life-cycle and decided to adapt our naming methodology more closely to our established processes. We will continue the practice of issuing a new release every 2 weeks.
Alpha version
We will publish alpha releases in the first phase of our development life cycle. Features that are planned for the final version will be added iteratively through the alpha phase. APIs can and will change, features may die or be added to without warning.
We will stop publishing alpha versions when we enter feature freeze, indicating that no more features will be added to the software (i.e., “feature complete”).
Beta version
In the feature freeze phase, we will publish beta releases. Beta versions will generally contain bugs, as well as likely speed/performance issues and may still cause unwanted crashes. Minor changes to surface and significant change to docs, training materials etc. can be expected.
We will stop publishing beta versions when we enter code freeze, indicating that the once wide open door to updating now nearly finished product is closing. All pull requests to update software code will be closely monitored and approved only if they add to overall quality and stability of the product.
Release Candidate version
Whilst in code-freeze, we will publish one or more release candidates (RC). RC is a version with potential to be a final product, which is ready to release unless significant “release-blocker” regressions emerge. All pull requests to update software code at this stage will require “exception approvals”.
This phase ends with GA release and a big party in our offices and (hopefully) delighted customers.
Reindeer Graph, with compiled Cypher
Remember the Reindeer Graph from last year? The Reindeer Graph models a team of reindeer, arranged in pairs except for the lead, all pulling a sleigh. Upon initial creation (see gist), the graph looks like this:
In Neo4j 3.2 cycle, we will be improving “compiled” runtime for Cypher. In the compiled runtime your query is no longer interpreted but transformed into bytecode to be executed by the Java Virtual Machine like all the other parts of Neo4j. This benefits both execution performance and memory efficiency, especially on queries that touch a lot of data and return larger payloads. Although only some of the operators are supported as of now (e.g. simple MATCH, property access, simple index lookups, WITH, SKIP, LIMIT and the id() function), more will follow soon. Using PROFILE or EXPLAIN you’ll see which runtime is eventually used as Cypher falls back to the regular interpreted runtime if it can’t run your query with the compiled runtime.
Here is one example on the Reindeer graph.
cypher runtime=compiled profile
MATCH (v:Vehicle {type:"Sleigh"})<-[:PULLS]-(d:Reindeer)-[:FOLLOWS]->(d2)
-[:FOLLOWS]->(d3)-[:FOLLOWS]->(d4)-[:FOLLOWS]->(d5)
RETURN *
Notable Changes
For this release, some notable changes include:
- RULE planner in Cypher removed. COST based planner is now default, one and only
- Introduced lock acquisition timeout
- Use label scan store by default if possible for schema index population
- More details are available in the 3.2 Changelog
Cheers to All!
Thanks to your continued feedback about Neo4j, we’ve been able to focus our attention on what’s most important to you. Neo4j 3.2 alpha 1 is available for download today as part of our Early Access Program.
Send your feedback to feedback@neotechnology.com or raise an issue on GitHub. If you have any questions, feel free to ask on our public Discord channel or post in our Google Group.
