Define a flow for patching UnifyCore

[rzr]

Since z-p-c was separated from UnifySDK-1.6, further effort should be done for cross project developments.

zpc-1.7 is adding UnifySDK-1.7 as a dependency, but may need to be patched or zpc features (a re-architecture maybe be desired to isolate generic features).

The current patches are stacked in this branch:

https://github.com/SiliconLabs/UnifySDK/tree/z-wave/core/zpc/main

On each Unify feature addition, some files should be re-generated and committed:

     git clone  https://github.com/SiliconLabs/UnifySDK/ -b z-wave/core/zpc/main
     rm -rf build ; cmake_options=-DZAP_GENERATE=ON ./helper.mk
     git commit -sam 'feat(zap): Regen zap files for feature F"

Then a series of patch can be generated using this command:

git  -C UnifySDK rebase -i ver_1.7.0  # To make sure the branch is on the right base used for export
git  -C UnifySDK  format-patch --no-numbered -o z-wave-protocol-controller/patches/UnifySDK/ ver_1.7.0
git -C  z-wave-protocol-controller -sam "p/Unify: Add patches for feature F"

To not loose trace of the flow, I keep trace of alignment in fork:

• https://github.com/SiliconLabsSoftware/z-wave-protocol-controller/tree/ver_1.7.1/patches/UnifySDK
• https://github.com/rzr/UnifySDK/releases/tag/ver_1.7.0.1

Further patches should stack on:

• https://github.com/SiliconLabs/UnifySDK/tree/z-wave/core/zpc/main

When patches are merged in zpc, then make sure to also push them UnifySDK , for the next serie.

This maintenance mode is not sustainable, and alternative would be use UnifySDK branch and to avoid floating code, tag it with a zpc scheme, or resume UnifySDK development in main branch.

Relate-to: https://github.com/SiliconLabsSoftware/z-wave-engine-application-layer/issues/6

[lmolina]

I understand that:

• The UnifySDK main branch (https://github.com/SiliconLabs/UnifySDK/tree/main) is not receiving any new development
• Some development on z-wave-protocol-controller requires new patches on UnifySDK, and therefore this patches go into the "transient" branch https://github.com/SiliconLabs/UnifySDK/tree/z-wave/core/zpc/main
• z-wave-protocol-controller depends on the UnifySDK tag 1.7.0, which is pulled on build

  z-wave-protocol-controller/cmake/modules/FindUnifySDK.cmake

  Lines 17 to 25 in 0063214

  	if("${UNIFYSDK_GIT_REPOSITORY}" STREQUAL "")
  	set(UNIFYSDK_GIT_REPOSITORY "https://github.com/SiliconLabs/UnifySDK")
  	endif()
  	if(NOT DEFINED UNIFYSDK_GIT_TAG)
  	if(DEFINED ENV{UNIFYSDK_GIT_TAG})
  	set(UNIFYSDK_GIT_TAG $ENV{UNIFYSDK_GIT_TAG})
  	else()
  	set(UNIFYSDK_GIT_TAG "ver_1.7.0")

As a consequence,

• The current flow is to have a dedicated patched branch on UnifySDK, then extract and store the patches on z-wave-protocol-controller and apply the patches on build time

Assuming that all this is because there is a requirement to not merge anything new into UnifySDK, what is preventing one of the following:

• point z-wave-protocol-controller to https://github.com/SiliconLabs/UnifySDK/tree/z-wave/core/zpc/main instead of the tag?
• set a tag on https://github.com/SiliconLabs/UnifySDK/tree/z-wave/core/zpc/main, and use it on z-wave-protocol-controller?
• point z-wave-protocol-controller to a commit ID on https://github.com/SiliconLabs/UnifySDK/tree/z-wave/core/zpc/main?

[rzr]

I avoided to tag upstream UnifySDK to avoid to create mess in this project in sleepy stage, so i tagged my fork.

Put if you want to point to a branch or rev that would be much easier to manage than a series of patches, in the end it will be the same.

I let you manage this project how you want since i am no more part of org, good luck feel free to ask any hints if needed.