Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Godot-Blender-Exporter branches renamed #238

Open
Jason0214 opened this issue Jul 30, 2019 · 2 comments
Open

Godot-Blender-Exporter branches renamed #238

Jason0214 opened this issue Jul 30, 2019 · 2 comments
Labels

Comments

@Jason0214
Copy link
Collaborator

We just did a branch renaming in Godot-Blender-Exporter repository to better organize support for different Blender versions. Now the branch naming has the same convention as GodotEngine, that is, master branch is going to be the active developing branch and blenderX.XX is going to be the stable branch for specific Blender version.

For people who find their local branches' upstream broken:

  • original master branch is the current blender2.79 branch
  • original blender2.8 branch is the current blender2.80 branch
@Jason0214 Jason0214 pinned this issue Jul 30, 2019
@akien-mga
Copy link
Member

akien-mga commented Nov 22, 2019

@Jason0214 I see that the blender2.80 and master branch have already diverged somewhat (6 "new" commits, 24 behind).

Since we don't expect major compatibility breakage in the 2.8x branch, I would suggest that we ensure that the master branch works on both 2.80 and the newly released 2.81, and thus remove the blender2.80 branch.

If we reach a point where keeping support for older 2.8x releases is too much hassle, we can then branch off to a known working commit and leave that as a legacy branch, like we have for blender2.79. WDYT?

Edit: Gives #292, I guess my proposal is maybe not so good. It might actually be painful to keep compatibility with more than one or two Blender versions if they break the API in each release.

@Jason0214
Copy link
Collaborator Author

Jason0214 commented Nov 24, 2019

Sorry, I have been busy in the last few months.

that the blender2.80 and master branch have already diverged somewhat (6 "new" commits, 24 behind).

As far as I remember most of the "new" commits on master branch need to be cherry-picked to blender2.8, I intended to do so, but looks like I forgot.

It might actually be painful to keep compatibility with more than one or two Blender versions if they break the API in each release.

I agree with this part, you never know where it will break, so 'maybe' it will immediately get complicated at some point.
What I intended to do for the current blender2.80 and master is that when merge commits always check if it applies to the other branch, if so does cherry-pick. It is actually easy to do because at merging PR, you know exactly whether it is a version break or a legacy fix. But this way we will have more branches and may confuse users and contributors.

Either way there are some inconvenience, I kind of prefer keeping individual branches for each 'breaking release'. If we do maintain the version well, we can probably hard code a version checking in addon loading and user would immediately know when they downloaded a wrong branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants