Follow 4D version : A Smarter Way to Manage your Dependencies

Great news! When adding a dependency from GitHub, you now have access to a brand-new rule: Follow 4D version. This powerful addition ensures your dependencies stay in sync with your 4D environment effortlessly, reducing compatibility issues and making your workflow smoother than ever.

SIMPLIFY YOUR DEPENDENCY MANAGEMENT

With the Follow 4D version rule, you no longer need to manually track which dependency versions align with your 4D version. The Dependency Manager takes care of it for you, ensuring that the most relevant and compatible versions are selected automatically. This means:

• Less manual work : no need to search for the right versions yourself.
• Fewer compatibility issues : your dependencies always match your 4D environment.
• More stability : keep your project running smoothly, even when updating or downgrading 4D.

EFFORTLESS UPDATES & RELIABLE COMPATIBILITY

When you upgrade your 4D version, your dependencies remain valid, and you can easily fetch the latest compatible versions. If you downgrade, the system will automatically adjust your dependencies to match your new version.

TAGGING RELEASES FOR AUTOMATIC RESOLUTION

To make this system work effectively, contributors must ensure that dependencies follow a structured tag naming convention. The Dependency Manager will resolve dependencies based on these versioning rules:

LTS versions : Tags must follow the pattern x.y.p, where:

• x represents the major 4D version.
• y represents the minor version.
• p allows flexibility for patch versions or additional updates.

Example: 20.2.3 (Major: 20, Minor: 2, Patch: 3) or 21.6.1 (Major: 21, Minor: 6, Patch: 1).

When your project specifies that it follows a 4D LTS version (e.g., 20.2), the Component Manager will always try to resolve to the latest version in that 20.* series if it’s available. If the exact version you’re looking for isn’t found, it will automatically fall back to an earlier version in that series, like 20.1.p or 20.0.p, if those are available.

R releases : Tags must follow the pattern `xRy.p`, where:

• xR corresponds to the major release version.
• y represents the minor version.
• p allows for patches and incremental updates.

Example: 20R3.2 (Major: 20R, Minor: 3, Patch: 2) or 21R5.1 (Major: 21R, Minor: 5, Patch: 1).

When your project specifies an R release like 20R3, the Component Manager will first try to resolve to the latest version in the 20R3.p series. If that version isn’t available, it will look for a version in the 20R* series that’s lower than or equal to 20R3, such as 20R2.p or 20R1.p.

4DPop and 4DPop-Macros components already adhere to the structured tagging conventions and will ensure smooth dependency resolution with the Follow 4D version rule.

Note that if you have your own components with custom naming rules, you can keep your version number in the title. However, the tag should strictly follow the required format.

FOCUS ON YOUR CODE, NOT YOUR DEPENDENCIES

With Follow 4D version, managing dependencies has never been this simple. Whether you’re upgrading, downgrading, or maintaining your project, you can trust that your dependencies will always align with your 4D environment.

Try it now and experience a smarter, hassle-free way to manage dependencies!