Move upstream to the docking branch

[wroyca]

Nowadays, ImGui is used almost exclusively with its docking features. This PR move upstream to reflect the docking branch.

[Rookfighter]

Hi @wroyca,

sorry for the late reply. Thanks for the PR and the note on the docking branch.

@boris-kolpackov maybe this coincides with your plans for integrating the imgui docking feature.

As far as I can see, the "official" releases of the upstream repo (and the corresponding tags) are still based on the master branch (not docking). As a result, I assume that still many users are using the non-docking versions of imgui, so IMO we should keep supporting the official releases. However, I am always open for discussions / arguments on why we should drop the official releases.

I would rather suggest that we create a separate package for the imgui docking support, so package consumers can choose which one they want to use. Now, I would prefer to not duplicate this whole repo for the docking version, but do something smarter. We could of course use a config flag to distinguish which version should be used, but a separate package seems more appropriate. Creating a docking branch on the package repo (where the packages have different names) would be also an option, however this might conflict with the bdep release versioning scheme (tagging). Maybe a fork / copy of the repo is still the best option? @boris-kolpackov any ideas on this?

One more point on this topic: It seems that the docking branch does not get tagged when a new version is released. Convention seems to be that master is tagged with the corresponding version and then master is merged to the docking branch. Just saying that it might introduce additional maintenance effort for matching the docking branch versions with corresponding master branch versions (to keep versioning of the build2 package consistent).

[wroyca]

IMO we should keep supporting the official releases.

Agree

I would rather suggest that we create a separate package for the imgui docking support, so package consumers can choose which one they want to use. Now, I would prefer to not duplicate this whole repo for the docking version, but do something smarter.

Also agree

I'm open to suggestions on what we could do, maybe Boris will have some suggestions on how we should handle this

[boris-kolpackov]

Yes, I agree, if upstream doesn't feel like docking belongs in master for whatever reasons, neither should we. A separate package (e.g., libimgui-docking) feels like the way to go. Of course, here we have 14 packages, which makes things a bit messy.

Creating a docking branch on the package repo (where the packages have different names) would be also an option, however this might conflict with the bdep release versioning scheme (tagging).

Yes, that's a good point, tagging won't work.

Maybe a fork / copy of the repo is still the best option?

That's probably the most straightforward option.

Another idea is to add another submodule (e.g., upstream-docking) that points to the docking branch and create the *-docking packages next to the existing ones. This could work seeing that the two branches are released essentially in lockstep and so for each release we will produce the complete set of packages. Also, this will potentially allow us not to duplicate certain packages (e.g., examples). We haven't done anything like this before, but we could try.

[wroyca]

@Rookfighter If you feel like we should experiment with another submodule, as Boris said, I wouldn't mind adapting my PR (e.g. creating a new branch ) to reflect that!

[Rookfighter]

@wroyca sure, go ahead. I think I won't be able to work on adding docking support myself, but I will happily assist (if I can) and review your changes :+1:

[boris-kolpackov]

Pull the docking branch by default

FYI, this doesn't seem to match the approach we agreed to try.

[wroyca]

Pull the docking branch by default

FYI, this doesn't seem to match the approach we agreed to try.

I'm aware - The pull request is associated with my personal repository, and it appears that some folks depend on it to ensure their project remains synchronized with the upstream's docking branch. Regarding the suggested approach, any changes should be implemented in a separate branch to avoid dependabot and to account for the fact that it would be very experimental. That said, I don't mind if you decide to close the pull request and initiate the conversation on a relevant issue instead. ☕

I've also mentioned it here:

I wouldn't mind adapting my PR (e.g. creating a new branch ) to reflect that!

[wroyca]

I am closing this since I don't have enough time to work on it, and periodically updating the submodule meets my requirements adequately for now 😅