How to develop Bosch SHC from now on (after v1.0)

[GerdZanker]

Dear Developers, @coeing and @stefan-kaestle,

the Bosch SHC code is now merged into openhab-addons/main. Therefore I suggest to switch from our development branch stefan-kaestle/bosch-shc-3.0 to "stefan-kaestle/main" and continue to use this forked repository and also the issue tracker for future development.

What do you think?

[coeing]

Yes, that sounds good! The branch name is outdated already, as openHAB is facing towards 3.1. We should have the current state in the main branch.

[tuxianerDE]

Hey,

one idea for structuring future release might be if we bundle topics to release milestones. As in:

• Internal release (enable parentel control framework, using proper units of measurement etc.)
• Light enhancement release (can include handling of Zwischenstecker, Light Control)
• Heat enhancement release (as in wall thermostat etc.)
• Security release (fire detection, setting the alarm etc.)

Does not mean that we dont release to the main branch everything at once but at least we could structure our changes in bundles alining with the milestones, as a thought.

[GerdZanker]

Fine! Then lets use main. This results in the follow repository branches and usages 1) openhab-addon/main -> official pull request target branch if we do more releases and main branch to start new developments 2) stefan-kaestle/main -> Bosch SHC main branch used to merge our feature branches, prepare releases and beta versions. We should do pull request reviews to merge changes and not push directly into this branch for a better quality. 3) OPTIONAL stefan-kaestle/feature/#xx -> Feature branches for a reported issue 4) OPTIONAL <ownFork>/<ownBranch> -> any other development later merged back via pull request into stefan-kaestle/main

[GerdZanker]

Hello @stefan-kaestle, I pushed the main branch into this repo. Can you set this branch as the default here in the branches overview please?

[coeing]

@GerdZanker Just checked the main branch. I would suggest that we just merge the changes from openhab-addons/main into our main branch instead of doing a rebase. This way our commits with their detailed commit messages remain intact. What do you think?

[coeing]

This is how it would look like in the git graph:

We can probably create a release branch from our main branch once we want to create a pull request for the openHAB repository. This release branch can be modified during the pull request. Once it is merged we just merge the openHAB main branch back into our main branch. Hope this is understandable :)

[coeing]

@GerdZanker I created a main-with-merge branch, so you can check how the structure would look like. Data-wise it is identical with the current main branch. If you are fine with it I would prefer to have our past commits saved for future reference :)

[coeing]

@GerdZanker I would like to base my pull request for #62 (and #74) on the new main branch, so it would be great if we could get a final solution here :)

[GerdZanker]

Please continue with your pull requests using your branches as the solution for us. I will adapt my contributions to your git way. If we find drawbacks we can change it in the future.

My personal experience is to rebase more often compared to merging to get simpler, cleaner gitlogs.

[coeing]

Please continue with your pull requests using your branches as the solution for us. I will adapt my contributions to your git way. If we find drawbacks we can change it in the future.

My personal experience is to rebase more often compared to merging to get simpler, cleaner gitlogs.

Yes, I like rebasing as well. But rebasing AND keeping our commits would mean to rebase all the commits from the start of the binding, which is not fun ;) So merging the openHAB main branch every now and then seems like a good compromise. As you said, we can change it if we encounter severe disadvantages with it 👍

[coeing]

Closing this as we seem to agree on the important points :)