master <-> crate

[jangernert]

Not sure why it was decided to go this way.
I think master is used to have the git version of every gtk dependencies and of course the latest features, while the crate branch is the branch to be released.

#63 (comment)

If I recall correctly, the master and crate branches are handled differently in this project: we cannot just merge one from the other.
Maybe that should be something worth fixing.

#91 (comment)

master still needs to be brought up to speed with the rest of gtk-rs (GTK 3 repository is now called gtk3-rs). There are two PRs that started the update: #89 #88

What is the plan here? Continue with two independent branches or bring them back together? Any contributions that are in master but missing in crate?

[antoyo]

I guess if someone could fix the branches so that we can just merge one into the other instead of doing the codegen for both, it would be nice.

[ghost]

As an end user of this crate, having two branches, one with stable dependencies and one with Git dependencies, is quite useful.
Perhaps this repository could have some sort of GitHub workflow to automatically update both branches? It would:

1. Update the gir and gir-files submodules
2. Call make gir
3. Push the changes to the branch it's updating

The only potential issue with that that I can see is the manual tweaking that's required (make gir generates bindings for an older version of GTK3) to resolve build errors. I had to do that in several places when I was working on PR #89.