beegfs_8 symlink missing on https://www.beegfs.io/release/

[frsc-ku]

On https://www.beegfs.io/release/ the symlink "beegfs_8" that follows "version 8 latest stable" is missing. Beegfs_6 and beegfs_7 are present. Could you please fix that? I would like to use a repo that follows "8 latest stable" instead of being pinned to a minor version.

[iamjoemccormick]

Hi @frsc-ku ,

You’re right that beegfs_6 was a moving target for the latest stable 6.x release, but beegfs_7 was frozen to 7.0. Starting with BeeGFS 7, we began publishing each patch release in its own version-specific repository (e.g., beegfs_7.2.3/) rather than updating a shared beegfs_7 path. This was a deliberate move to prevent unintended upgrades, especially in environments with auto-updating package managers, since not all 7.x patches were fully backward compatible.

As of BeeGFS 8, we’ve adopted semantic versioning. Now:

• Patch releases within a given minor (e.g., 8.0.1, 8.0.2) are guaranteed to be backward compatible.
• Each minor release (e.g., 8.1, 8.2) gets its own directory (beegfs_8.1/), and we reserve the right to push critical, auto-updated patches within that path.

We’ve intentionally not published a generic beegfs_8 symlink, because:

• Minor versions can introduce new features or behavioral changes.
• Admins should ideally read the release notes and follow the upgrade guide before rolling out a new 8.x version fleet-wide.

That said, if there’s demand for a moving beegfs_8 stable symlink, we’re open to revisiting that. Let me know if this is critical for your workflow and I’ll raise it internally.

[frsc-ku]

Hi Joe,

thanks for your fast response. It would be great to have a floating target if my interpretation of "This means BeeGFS 8.1.0 components are compatible with components running any BeeGFS 8.y.z release" under https://doc.beegfs.io/latest/release_notes.html#version-interoperability holds:

• Semantic versioning and compatibility with "any 8.y.z release" means that partial updates and daemon restarts (in any order!) will not lead to system crashes (BeeGFS will run on a mixed version installation). There might be temporary service outage, but clients will reconnect and continue after that.
• Features that change behaviour in a non-backward compatible way are always disabled by default and an administrator needs to read the release notes for how to enable new features.
• New features that were not enabled before must never be enabled automatically, for example, on a cluster with mixed versions with exactly one daemon on the lowest version a restart of this one daemon must not enable new features supported by the next-lower version. Enabling new features with minor version upgrades are always manual operations.

If your intention is to follow these requirements, then a floating target would be really helpful and it would be great if you could create the symlink. For our workflow we have ansible playbooks updating our entire infrastructure and it would be great if we could add BeeGFS to that and to cover minor version upgrades as well.

If minor version upgrades can break any point in the list above, then please change the description at https://doc.beegfs.io/latest/release_notes.html#version-interoperability to include something like:

• For a fixed minor version y, any patch release "8.y.z" will be fully compatible with 8.y.0 (compatibility with 8.1.0 is not required and probably too strong).
• Minor version upgrades 8.y1.x -> 8.y2.z, y1<y2, require the attention of an administrator and to read the [release notes](please add link, couldn't find it).

Hope that makes sense.

Best regards,
Frank

[iamjoemccormick]

Hi Frank,

Your interpretation of the interoperability statement in the release notes is largely accurate. The only nuance is that, when feasible, we may introduce new features or behavioral changes that are enabled automatically (with graceful fallback when needed).

Notably, there are cases where we need to make tradeoffs between maintaining legacy behavior and improving performance or security. For example, we recently identified a significant ACL performance gain by caching directory ACLs for up to one second. We believe most users will prefer this behavior, so we intend to make it the default. However, some users may have strict requirements that ACLs must never be cached.

Additionally, even with semantic versioning, misconfigurations outside of BeeGFS can still lead to subtle and confusing behavior changes, even when all components remain interoperable.

These are the kinds of reasons why we generally discourage fully automatic updates. But if a user is comfortable with the fact that we may occasionally introduce functionally backward-compatible changes “for the greater good,” we have now created https://www.beegfs.io/release/beegfs_8, which will be maintained as a symlink to the latest stable BeeGFS 8.x.y release.

Aside: I appreciate the feedback on how our compatibility statements are interpreted. This is valuable input for us as maintainers to ensure our messaging aligns with community expectations.

Thank you,

~Joe

[frsc-ku]

Dear Joe,

thanks for making the moving target available. I was more concerned about "no way back" feature updates that might lead to data loss or similar in the situations I described. For our use case, the guarantees you plan to make are good enough to go with updating to "latest stable" during our normal update cycles. Note that these are not very frequent and we usually arrange for a service window. The compatibility requirements from our side are more of the kind "nothing catastrophic will happen if someone who doesn't know anything about BeeGFS runs the update". As long as the rule is that stuff comes up healthy without me being called up during holidays it will be fine.

A side node: the URL works. However, the index page https://www.beegfs.io/release/ does not show a beegfs_8 entry. Maybe that is intentional, maybe not. I would usually prefer to see that its there.

Best regards,
Frank

[iamjoemccormick]

Yes omitting the beegfs_8 from the release index page was intentional at this point. That way others can either find it through this discussion along with the context about the implications, or we can direct them to it on a case-by-case basis.