Release cycle #498
Replies: 4 comments 60 replies
-
Changing the build system isn't a breaking change for users as far as I can tell, and that is what the versioning is based on. As for other breaking changes, there has only been FTransform constructor which I think should not have been merged into main if the next version is to be 3.1. Otherwise next version has to be 4.0. Not against that at all. But if we do that, linux support and data table support should 100% by implemented by then as MVP (and by extension the build system fully chosen).
I wasn't aware of this about the hotfixes (as I had not realised the issue yet) and to be honest I don't think anyone else realised either, otherwise that 3.0.1 hotfix definately should have been blocked. But yes I agree this is what should be strictly kept to in the future. As for minor versions not breaking compatibility, that means even ABI cannot change in them too? I'm honestly not too sure how that will be possible, as the vast majority of fixes/changes changes it.
I very much agree, this would be very good. If we had this, xmake should have been merged into say, 4.0 branch, then linux port can base off that branch, while breaking changes can continue to go into that branch while other things can go into 3.1 branch or similar. UEPsuedo would also then need to use the same system and I think our docs build script would likely need to be updated to work across branches. I think narknon wanted something similar. @narknon can you share again what it is you wanted to do with this? |
Beta Was this translation helpful? Give feedback.
-
|
Developing for minor release branches somewhat misses the point of the "next-minor" paradigm. The point of next-minor is that any active development targets the next-minor release. If a breaking change is introduced, then the "next-minor" bump will happen to be a major bump, but that's the system working as intended. Envision each tag as a full invocation of the release deployment actions. I tried to show that releases aren't triggered upon successful merges into main/minor branches, but can instead be automated on a time based cycle, commit based cycle, manual deployment, etc. It's also important to notice how the hotfix needed for v3 did not need to be ported all the way back to the v3.0 branch. This is because all flavors of 3.x should be compatible with each other, so we only need to hotfix the latest minor version of the major versions we want to fix (3.1 in the diagram's case). We could also backport the fix to whatever the latest 2.x branch is as a patch bump. For anyone that might be overwhelmed by the branches, notice that each dev is only doing work on the main branch UNLESS they choose to cherry-pick a fix into a previous major version. The entire process is streamlined on the main branch since we're always targeting the "next-minor" version instead of developing for a collection of "maybe-these-are-active" branches. In the diagram, everything above the main branch is dev-land and everything below the main branch is automation-land. The only time a dev has to cross into the underworld is for the hotfix cherry pick process (which will be made easier by clear documentation and some automated sanity tests to make sure you aren't trying to change 200 files or bring an entire branch worth of commit history in the hotfix) |
Beta Was this translation helpful? Give feedback.
-
|
@bitonality That would just needlessly force us to push major updates out immediately when we happen to have one major feature ready or it locks us out of releasing minor changes or hotfixes quickly. As far as automation is concerned, I don't think releases should ever be fully automated, that's just not gonna work, we'll just end up with releases without any actual changes or releases with changes so small that they don't justify a release. |
Beta Was this translation helpful? Give feedback.
-
First, I wasn't aware that was possible. |
Beta Was this translation helpful? Give feedback.
-
I agree with your assessment IF we're frequently breaking compatibility. It we're worried about frequent major version bumps then it might be worth asking ourselves - why are we introducing ABI/API breaking changes so frequently? It's understandable that we're going to have a lot of layout changes (struct defs, unions, vtable layout, alignment) due to the close coupled nature of this project with the UE runtime. I pose the following question: Is the burden of compatibility something that should be federated to developers and reviewers, or should it be the burden of the release manager/maintainers? The following proposal is authored under the assumption that ABI breaks are an inevitable pain point of our current API/ABI/system design. The solutions I'm describing put the majority of the compatibility burden on individual devs who are breaking the compatibility instead of on maintainers/release management. Feature FlightingPerhaps we could ship a thin feature flag/flighting mechanism that would go something like this? struct SomeUEStruct {
int myNum;
int anotherNum;
}
// Needs to change to:
struct SomeUEStruct {
long myNum;
int anotherNum;
}
// Here's the flighted definition
struct SomeUEStruct {
#if feature_bitonality_struct_change
long myNum;
#else
int myNum;
#endif
int anotherInt;
}Nightly/main builds would be executed with The flighting system would require some light tooling to be developed and we would have to arrive at a schema. This basic implementation would be greppable on The general flow would be
Automatic Releases?I agree that automatic releases (other than potential nightly builds from main) should be avoided. Feature flights provide a nice heuristic about when it might be a good time to consider a release. Something like:
ToolingI acknowledge that the tooling would have to be implemented up-front and that does not come without cost. However, it saves a ton of work for the release management team/merge monkey that will inevitably become a pain point whenever release branches need their changes brought into main. We could very easily roll a pass-required PR check that runs ABI test against the PR branch. If ABI incompatibility is detected, then we automatically add a comment to the PR saying "You're breaking ABI, here's the recommended way to flight your changes". We could even support an override mechanism that maintainers could execute that says "You're breaking ABI, but the council has determined that this change is un-flightable and WILL require a major version bump". Feature flighting has the advantage of allowing newly merged code paths in main to get a lot of execution testing (since devs will likely be testing/developing against main AND any nightly users would also be executing these paths). In my estimation, this would lead to more executions of new code as opposed to cutting a pre-release or beta branch and expecting the same throughput of testing by volunteers on those branches. ConclusionIn my mind, the internal developer workflow looks something like this: I'll keep advocating for true trunk based development, but I understand that this is a group decision. I'll be more than happy to assist with tooling for whatever solution we come up with. |
Beta Was this translation helpful? Give feedback.
-
In my opinion, there should be two parts to it.
In theory, this sounds fine, but this would have to be followed very strictly for every breaking change because a single breaking change will invalidate other flighted changes, which means the ABI won't be compatible. Would these defines stay in the codebase forever or would we remove them ? If we remove them, do we do it manually ? That's more overhead. Do we do it automatically ? More implementation + automated deletion of code could be dangerous especially if there's no robust solution already developed that can do it. Do we not delete it ? Then we'll end up with a very messy codebase over time.
Notifications sound like a good idea.
Can we though ? We still have that problem where we can't run any github actions that build UE4SS because of a lack of access to the UEPseudo repo from random peoples account.
Provided we have a robust way to make sure breaking changes are properly flighted, this might be able to work, but I provided my skepticism about that above. |
Beta Was this translation helpful? Give feedback.
-
|
Sidebar - Opened a discussion for API/ABI compatibility detection tools since that can be decoupled from this discussion imo. |
Beta Was this translation helpful? Give feedback.
-
|
The issue with all of these proposals is the complexity for maintainers. Bit is also proposing different tools to make it be less of a burden on maintainers, which could make it tolerable, but then we are relying on those tools to not break/more complexity and going full circle. Nearly all releases haven't been delayed due to some feature issue, they've been delayed due to someone finding the time to make a release. Same with most merges. That is also why most merges have been under-tested. The proposals here are all more complex than most repo management policies for official salaried projects. @UE4SS I don't mean this in a hostile way, but you should be the first to admit that maintainers may need to drop at any time for their own personal reasons. That is fine, this is a hobbyist project. But someone else should be able to jump in at that point and continue the maintenance without a major learning curve. I haven't been very active lately. At times, I've been the only active maintainer. If everyone else quit tomorrow, I feel like the project's complexity has ballooned to the point that I could no longer find the motivation to try to maintain it alone. The proposals here all add to that feeling, and I think if anyone here considered it from that perspective they'd agree. I don't think we should rely on anything that requires specific people to stick around. All this being said, I propose that we return to using a release and dev branch. If there is a release branch, you can cherry pick hotfixes into it and make a release at any time. You can decide that a certain major feature isn't ready yet, and PR a minor feature to both branches if you wish to not break ABI quite yet. SemVer can be followed. It solves all the same issues with far less complexity and manual work for maintainers. If it ends up not quite meeting our needs, the dev branch can be expanded to include other branches as needed. Often, the simplest solution is the best, and I think instead of jumping into one of these more complicated solutions we should go back to basics with an expandable method. Even if it ends up not working out, it's much easier to then decide to move from it to one of these other methods rather than the reverse. |
Beta Was this translation helpful? Give feedback.
-
When did I ever say otherwise ? Regardless, I don't think what I suggested is particularly complicated, nor does it force anyone to do anything. At this point, I feel like we're deadlocked three ways. |
Beta Was this translation helpful? Give feedback.
-
|
What benefits does your proposal have over a release branch? We shouldn't fall into the trap of requiring specific features to be finished for future releases, when those features could end up abandoned, and having different Major branches way ahead of their planned release just encourages that. Separately, a release/dev branch system effectively does the same thing as "next-minor", except without creating a branch for every minor release. |
Beta Was this translation helpful? Give feedback.
-
|
@narknon |
Beta Was this translation helpful? Give feedback.
-
|
By cherry-picking from a tag, I meant checking out the tag and pushing a branch from it with the hotfix. Not ideal and should be avoided, but it is a possible solution for emergencies with our current method or for release/dev. |
Beta Was this translation helpful? Give feedback.
-
|
I think we're conflating two problems here, which is branch management and ABI/SemVer management/merging of features. I don't think branch management is the solution to our current tendency of merging features that aren't quite ready and breaking ABI before a full release can be made. On the other hand, we shouldn't be afraid to break ABI when we actually have features ready. Therefore, I think for now we go with release/dev and revisit this after we get some better merge discipline if it is still necessary to tackle it from the branches side. Again, it is much easier to go from a simpler solution to a more complicated one than it is to do the reverse, and this is not a final say on anyone's proposals never being implemented. I'll leave discussion open for another day. |
Beta Was this translation helpful? Give feedback.
-
|
Am I understanding it correctly that we have release for the current latest release that we merge into once we cut a release, and dev where we develop everything? If so, I support this solution as this is the easiest for me to understand and doesn't involve any mental fatigue. |
Beta Was this translation helpful? Give feedback.
-
|
This however has the downside of us not being able to add patches to previously released versions, but could it be done by just creating a branch off of release, fixing an issue and merging it into release therefore cutting a new patch release, and cherry-picking it into dev (or vice versa)? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, exactly that. Hotfixes can be developed for main and cherrypicked into dev if they're still applicable. |
Beta Was this translation helpful? Give feedback.
-
|
How do we feel about supporting a previous major release for a certain period so that if a serious bug arises we can provide some support to the developers/modders that still use ue4ss on the previous major? So we would have a new branch be cut right before merging a new major into |
Beta Was this translation helpful? Give feedback.
-
|
There should be some period like that but 3 months is much too long and I'm hesitant to put any hard requirement on it right now. We can play it by ear a bit to start. |
Beta Was this translation helpful? Give feedback.
-
Place to continue conversation in #494, first comment here, please read down from there for full context.
Beta Was this translation helpful? Give feedback.
All reactions