elDoc versions overview:

• v7.2026.2
• v7.2026.1
• v5.11.1
• v5.11.0
• v5.10.0
• v5.9.2
• v5.9.1
• v5.9.0
• v5.8.9
• v5.8.8
• v5.8.7
• v5.8.6
• v5.8.5
• v5.8.4
• v5.8.3
• v5.8.2
• v5.8.1
• v5.8.0
• v5.7.4
• v5.7.3
• v5.7.2
• v5.7.1
• v5.7.0
• v5.6.1
• v5.6.0
• v5.5.3
• v5.5.2
• v5.5.1
• v5.5.0
• v5.4.6
• v5.4.5
• v5.4.4
• v5.4.3
• v5.4.2
• v5.4.1
• v5.4.0
• v5.3.8
• v5.3.7
• v5.3.6
• v5.3.5
• v5.3.4
• v5.3.3
• v5.3.2
• v5.3.1
• v5.3.0
• v5.2.0
• v5.1.2
• v5.1.1
• v5.1.0
• v5.0.12
• v5.0.11
• v5.0.10
• v5.0.9
• v5.0.8
• v5.0.7
• v5.0.6
• v5.0.5
• v5.0.3
• v5.0.2
• v5.0.1
• v5.0.0

Version Scheme

Starting in January 2026, elDoc adopts a new versioning scheme: Major.Year.Minor. The first release using this scheme is v7.2026.1.

Upgrade and Compatibility Policy

Minor Version Upgrades (e.g., 7.2026.1 → 7.2026.2)

Upgrades within the same major version are designed to be fully automated and non-disruptive.

When upgrading between minor versions of the same major release:

• Database migrations are performed automatically at startup

• Internal metadata and indexes are upgraded automatically

• No configuration changes are required

• No manual upgrade steps are expected

Example:
7.x → 7.y upgrades do not require configuration updates.

Backward compatibility is maintained across minor releases within the same major version.

If an exceptional backward-incompatible change is introduced in a minor release, it will be explicitly documented in the Release Notes.

Major Version Upgrades (e.g., 7.x → 8.y)

Upgrades between major versions may introduce architectural or configuration changes.

When upgrading from one major version to another:

• Database and internal data migrations remain automated

• Configuration updates may be required

• Manual review of Release Notes is mandatory

• Configuration adjustments must be performed explicitly where documented

Example:
7.x → 8.y upgrades may require configuration changes or manual adjustments.

Major upgrades are designed to remain structured and controlled, but they may introduce new configuration properties, deprecated settings, or behavioral changes.

General Upgrade Requirement

Before any upgrade:

• A valid and recent database backup must be in place

• Release Notes for the target version must be reviewed

elDoc Product Lifecycle and Upgrade Model

Continuous Evolution – Automated Forward Upgrade

elDoc does not follow a traditional End-of-Life (EOL) lifecycle model. Instead, elDoc follows a continuous forward-upgrade strategy.

Each release includes built-in migration logic that automatically upgrades:

• Database schema and collections

• Internal document metadata

• Index structures

• System components where required

Upgrades are performed in-place during application startup.

There are no parallel product generations and no forced platform migrations. Each version builds directly on the previous one.

Actively Maintained Versions

Maintenance efforts are concentrated on the latest minor release within the current major version.

For example, if the current release stream is:

• 7.2026.1

• 7.2026.2

• 7.2026.3

Then 7.2026.3 is considered the actively maintained version.

Earlier minor releases within the same major version remain upgradeable through the automated migration mechanism but do not receive independent maintenance branches.

This model ensures:

• A single active maintenance stream

• Predictable upgrade paths

• No fragmented support branches

• Consistent security and stability management

Version Support Matrix

Long-Term Support (LTS)

In exceptional cases where upgrading to the latest actively maintained version is not immediately possible, a Long-Term Support (LTS) arrangement may be established individually.

LTS may include:

• Critical security fixes

• Essential component updates

• High-priority stability maintenance

LTS does not replace the standard forward-upgrade model.
Primary maintenance efforts remain focused on the latest minor release of the current major version.

Summary

• elDoc provides automated database and internal data upgrades.

• Minor upgrades within the same major version (e.g., 7.x → 7.y) require no configuration changes.

• Major upgrades (e.g., 7.x → 8.y) may require manual configuration updates.

• There is no traditional product EOL cycle – the platform evolves continuously through controlled forward upgrades.