All versions of this manual
X
Welcome to Linkurious administration manual v4.1.9. Use the menu to access other documentations.
  1. Introduction
  2. FAQ
  3. Getting started
    1. Version support policy
    2. Release notes
    3. Client requirements
    4. Graph DB Feature Map
  4. Deploying on premise
    1. Technical requirements
    2. Downloading
    3. Installing
    4. Starting Linkurious
    5. Stopping Linkurious
  5. Configuring
  6. Troubleshooting
    1. Checking Linkurious status
    2. Reading the logs
    3. Getting support
    4. Managing licenses
    5. Vulnerabilities
  7. Importing graph data
    1. Neo4j
    2. Memgraph
    3. Amazon Neptune
    4. Cosmos DB
    5. Updating your graph data
  8. Updating Linkurious
    1. Checking for updates
    2. Backing up your data
    3. Update procedure
  9. Configuring data-sources
    1. Neo4j
    2. Amazon Neptune
    3. Memgraph
    4. Cosmos DB
    5. Alternative IDs
    6. Merging data-sources
    7. Advanced settings
  10. Resource management
    1. Managing spaces
    2. Managing tags
  11. Search index
    1. Search Option Comparison
    2. Neo4j Search
    3. Elasticsearch
    4. OpenSearch for Amazon Neptune
    5. Azure Search
    6. Incremental Indexing
    7. Numerical/Date search
  12. User-data store
    1. Migrating to an external database
    2. Backing-up your store
  13. Web server
  14. Authentication
    1. Getting started
    2. LDAP / Active Directory
    3. SSO with Azure AD
    4. SSO with Google
    5. SSO with OpenID Connect
    6. SSO with SAML2 / ADFS
    7. Configuration
  15. Access control
    1. Managing users
    2. Managing groups
    3. Standard access-rights
    4. Property-key access-rights
  16. Guest mode
    1. Guest mode
  17. Data Schema
    1. Property types
    2. Hiding data
    3. Strict mode
  18. Alerts
    1. Configuration
  19. Email Notifications
    1. Configuration
  20. Visualizations appearance
    1. Default styles
    2. Default captions
    3. Default properties order
    4. Geographic tiles
  21. Audit trail
    1. Log format
  22. Webhooks
  23. Observability
  24. Plugins
  25. Deep link
 

Getting started: Version support policy

What is a version?

Linkurious Enterprise uses version codes with 3 numbers separated by dots (e.g. 2.9.14). The numbers are interpreted as MAJOR.MINOR.PATCH. For example, Linkurious Enterprise 2.9.11 is a patch version that is part of the Linkurious Enterprise 2.9 minor version, which is itself part of the Linkurious Enterprise 2 major version.

Version stability

When updating Linkurious Enterprise from one version to another (for any version in the “stable” or “maintenance” stage), the following is guaranteed:

  • A patch update (changing the patch version number, e.g. from 2.2.4 to 2.2.7) does not introduce breaking changes. A patch version (also called a corrective maintenance release) is used to fix defects and usability issues, and can introduce non-breaking improvements.
  • A minor update (changing the minor version number, e.g. from 2.2.4 to 2.3.2) may introduce improvements that include breaking changes.
  • A major update (changing the major version number, e.g. from 2.2.4 to 3.1.6) may introduce improvements that include significant breaking changes.

Breaking change

A breaking change is a change that either removes a feature, or changes an existing feature in a way that makes adopting this change require either:

  • active actions from a users or an admin (e.g. administrators must re-enable each alert)
  • changing existing code (e.g. change the code that uses an API to rename a parameter)
  • changing end-user processes (e.g. users have to change the way they search for dates)

Examples:

  • "Removed support for Elasticsearch v6 and older"
  • "Added a required 'group' parameter on the 'findUsers' API endpoint"
  • "Added a required 'target' parameter when creating an alert"

Non-breaking improvement

A non-breaking improvement is a change that either adds a new feature, or extends the capacities of an existing features without removing any existing functional behavior.

Examples:

  • "Added the ability to leave comments on alert cases"
  • "Added the ability to search on numbers in advanced search"
  • "Improved the performance of filters in visualizations"
  • "Added an optional configuration parameter to set the path of extra Certificate Authorities"
  • “Redesigned the layout settings panel to make it easier to understand”

Stages of a minor version

A minor version of Linkurious Enterprise (e.g. 2.9) is always in one of the following stages:

  • Beta: when a minor version (e.g. 2.9) is first released, it goes through a "beta" stage. During this stage, patch versions (e.g. 2.9.1) are released frequently to add new features and improve the stability.
    The version should not be used in production: the standard support terms do not apply, patch version may include breaking changes and defects will be fixed on a best-effort basis.
  • Stable: when a minor version (e.g. 2.9) is considered reliable enough, a new patch version (e.g. 2.9.5) is released and marked as stable, and the minor version officially becomes "stable".
    The version is recommended for use in production: the support terms apply, defects (including security issues) with a severity of at least "medium" will be handled in a timely manner and fixes will be made available via patch releases (see Support Policy Terms).
  • Maintenance: when the next minor version becomes stable, a stable minor version goes to the "maintenance" stage (e.g. when 2.10 becomes stable, 2.9 becomes maintenance). A version remains in maintenance for at least 6 months.
    The version can be used in production: the support terms apply, defects (including security issues) with a severity of at least "high" will be handled in a timely manner and fixes will be made available via patch releases (see Support Policy Terms).
  • End of life: when a version is not supported anymore, is goes into the "end of life" stage.
    The version should not be used in production: defects (including security issues) will not be fixed.

Release frequency

  • New major versions are released at most once per year.
  • New minor versions are released at most twice a year for the current major version.
  • Patch versions are released approximately twice a month, or more frequently if required to fix "highest" defects.

Support duration

  • A minor version (e.g. 2.9) is supported for at least 12 months after it becomes stable (of which approximately 6 months are spent respectively in "stable" and "maintenance").
  • A minor version goes from “stable” to “maintenance” when the next minor version becomes stable. From that day, it stays in maintenance at least 6 months.
  • Long Term Support (LTS) can be purchased for any minor version. Customers who purchase LTS for a version get an extra 6 months of maintenance support for that minor version.
  • When LTS is purchased for a minor version, its support is guaranteed to overlap with the support of the next minor version during at least 6 months.
  • To benefit from all fixes and improvements on a supported minor version, it is mandatory to update to the latest patch of that minor version.

Example life-cycle

This is an example version life-cycle to illustrate how minor and patch version are released. release lifecycle example diagram