We are beginning to work more heavily with branches, following much of the existing guidance regarding Fortnite’s branching strategy and release branches.
Our current setup involves a Main branch and a Release branch, with changes from the release branch being automatically RoboMerged back to Main and changes from Main going to the Release branch by request. All of this is generally working well for our purposes.
Unfortunately, we’ve run into a snag in regard to monotonic engine versioning. What happens is:
- A code change gets made on Main and an Editor build is produced. (e.g. 5.5.4-14966+++Main)
- Somebody then requests that change be integrated to the Release branch, which happens.
- A new Editor build is created on the Release branch. (e.g. 5.5.4-15002+++Release)
- Some changes to assets are made on the Release branch.
- Those changes to assets get automatically RoboMerged to Main before any further code changes have been made.
Sadly, Main now cannot load the asset:
LoadErrors: Error: Package ‘/Game/Foo’ has been saved with a newer engine version and can’t be loaded. Current EngineVersion: 5.5.4-14966+++Main (Licensee=1). Package EngineVersion: 5.5.4-15002+++Release (Licensee=1)
This is eventually corrected by a new Editor build on Main that *can* load the asset.
Obviously, there’s a lot of nuance to versioning and compatibility across branches, but let’s temporarily ignore that for this otherwise very straightforward scenario. Do people have good strategies for dealing with this in situations where they should obviously be compatible and simply aren’t due to the specifics of Perforce changelist numbering and the versioning scheme?
Hey there Zach,
Apologies for the delay as the team has been at an internal conference the past week.
I can suggest trying EnforcePackageCompatibleVersionCheck as a very temporary workaround, and I *do* see a couple internal packages that do this (which are in rapid development), but I also don’t see this error occurring too frequently based on some quick grepping. Let me follow up internally with some colleagues to see that the guidance is here. Just looking at our internal RoboMerge paths, I can see that we could theoretically hit the same issues, but again, incidence doesn’t appear to be common.
Kind regards,
Julian
Hey there Zach,
So I have followed up internally, and this is very much something we are theoretically exposed to, but due to our rate of churn in main-line this is not something we practically encounter (we generate PCB builds quite frequently, almost at a rate of every 5 or so minutes).
Some higher level feedback from the SME in this space:
- CL based engine versioning doesn’t accomplish it’s intended goals in a RoboMerge environment, as CL verification is really only valid in a single stream
- We are forcing the CL# in to every manually built version of the editor via UGS instead of having version 0 for the built engine, this means that there isn’t even the guarantee within a single stream that the user running an editor with cl# after the asset # can load it because the engine could have had local incompatible issues, and submitted the asset without submitting the changes that created them
Fundamentally speaking, the CL based versioning has it’s challenges in a Robomerge environment, but at the moment we tend to work around/with those challenges. I hope this provides some clarity on the limitations of Robomerge in this scenario, and that you indeed aren’t experiencing a unique edge case to your setup. I don’t see any efforts internally to address this at the moment due to the low incidence we encounter.
Kind regards,
Julian