Branch and release status

[mike-yesware]

I added this to another issue, but in retrospect this was too OT, so I'm moving it here.

I'm new to the project and trying to get a handle on the different branches and their intended future. This thread could be a good place to have a conversation about that and if I could help at all.

I've been lurking here meaning to post a question like @lorenwest's for a while. Seems like:

• There hasn't been a release for quite a while, so something like Platform.io is quite out of date
• master is quite stable, and can be used without much worry
• develop is ahead of master, but compatible with the API there?
• develop-v3 is a new API, so not backwards compatible?

TBH, the last two are most confusing to me as it seems like homie-esp8266 should be versioned itself, and it also wants to support two different versions of the Homie spec. At least, I think that's the current intention of the two branches.

Would there be interest in stable-v2 and a stable-v3 (or, just master) branches that releases can be cut from? I'm quite happy to help with any of the release engineering work if that's agreeable.

Please let me know if I've gotten any of this wrong.

[lorenwest]

@mike-yesware I'd be happy to work with you on this.

[euphi]

I think, we should write down clearly the current situation and then decide how to proceed.

Technically

• There is a stable 2.0 release
• There was progress for a 2.1 release, that is unfinished, see Towards V2.1 #458.
• There was a PR that implemented support for Homie convention 3.0.1.
  • The PR was based on 2.0, not 2.1 branch.
  • The PR was merged into a new branch #develop-v3.
• Based on the convention 3.0.1-PR there was another PR that implemented support for ESP32.
  • This PR was also merged into #develop-v3.
• Some smaller features from other PRs and V2.0 branch were merged (cherry-picked) to #develop-v3.

Organizationally

• @marvinroger moved the repository to homieiot organization and made some contributers "Member".
• Some invitations to become member are still open.
• Some people provided good PRs.
  • @bodiroga , @tantive, @luebbe, @stritti , @kleini : Are you interested and have time to support homie-esp8266 (or the convention / other implementations).
• I merged the PRs for convention 3.0.1 and ESP32, but don't really have the time for all maintainer duties.

Proposal

• The #develop-v3 is quite stable already. In my opinion, we should continue only this branch, release a beta soon - and create a new roadmap for new features.
• Some features already implemented in the never merged 2.1 branch may be cherry-picked to v3.

[kleini]

I totally agree, that we should decide rather early than later how the progress is with this project.

I like the Homie convention for MQTT and furthermore the coding framework. I tested ESPurna, Tasmota and so on and homie-esp8266 satisfies me most regarding my needs:

• MQTT over SSL
• no web UI crap for configuration (at least I can remove it with compiler flags)
• possible deep sleep for running on batteries (although it is still consuming way too much power in my cases)
• some good libraries for sensors
• all open and extensible
• maybe some more, that I forgot

I already tried to use homie-esp8266 and to support it as much as possible. I don't need to be a member. I can contribute with PRs and will continue to do so. If the projects way is to go the develop-v3 path, I will use that and contribute there. If you want to make me a member, how would you organize if some PR is good enough to be merged? Multiple people then need to be able to check everything necessary has been considered. Currently I don't know, what all needs to be considered.

Regarding ESP32: As this microcontroller has much more memory compared to ESP8266, does it make sense to stick to C++? If there is enough memory for easier programming languages, that way should be taken in my eyes. microhomie looks very promising in these regards.

[kpishere]

Pls. stick with C++. I'm firmly in the esp8266 camp and will not be using esp32 any time soon. esp32 is way over powered for my tasks. k.

…

On Mar 19, 2019, at 06:29, Marcus Klein ***@***.***> wrote: I totally agree, that we should decide rather early than later how the progress is with this project. I like the Homie convention for MQTT and furthermore the coding framework. I tested ESPurna, Tasmota and so on and homie-esp8266 satisfies me most regarding my needs: MQTT over SSL no web UI crap for configuration (at least I can remove it with compiler flags) possible deep sleep for running on batteries (although it is still consuming way too much power in my cases) some good libraries for sensors all open and extensible maybe some more, that I forgot I already tried to use homie-esp8266 and to support it as much as possible. I don't need to be a member. I can contribute with PRs and will continue to do so. If the projects way is to go the develop-v3 path, I will use that and contribute there. If you want to make me a member, how would you organize if some PR is good enough to be merged? Multiple people then need to be able to check everything necessary has been considered. Currently I don't know, what all needs to be considered. Regarding ESP32: As this microcontroller has much more memory compared to ESP8266, does it make sense to stick to C++? If there is enough memory for easier programming languages, that way should be taken in my eyes. microhomie looks very promising in these regards. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[luebbe]

I can help, but I'm afraid not much. The multitude of different unfinished branches scares me a bit. I'm very much in favor of cleaning up to get a 2.1 release out of the door and focus on 3.x afterwards.

[kleini]

I would fully support @luebbe. The existence of multiple develop branches towards different goals confuses contributors. There should be a clear plan, a roadmap and definitions, what v2.1 and v3.0 and any other target release should contain or not. Once those targets are clear, the community knows which tasks should be worked on.

[bertmelis]

After spending some time on esp32 and esp8266, I can only strive for a seperate esp32 repo. Imho esp32 should not rely on asyncmqtt. It runs on a rtos and multithreading, multicore + async is just hard to get reliable.

Mind, there is already a mqtt client available in the Arduino core for esp32 (via IDF).

[euphi]

@bertmelis eh. esp8266 runs on rtos and multithreading, too? (ok, its only 2 threads in arduino-framework, but thats still multithreading)

[euphi]

@kleini / @luebbe There is strong interest in a version that follows the v3 convention (and also in ESP32).
Thats why I merged the available PRs.
However, I also saw the unfinished 2.1 PR, so I don't wanted to change the current v2 development - therefore I created the #develop-v3 branch.

I also merged smaller PRs into both #develop and #develop-v3, so these are now in both branches.

So, whats open now?

• the 2.1 PR by @timpur - this looks very good, so I propose that this will be merged into #develop.
• I would also try to merge the 2.1 PR into #develop-v3. There will be merge conflicts, but this seem to be easy to solve.
• Testing. Especially of the #develop branch (v2), so that it can be released as 2.1.

For my part: I'm deploying a quite large homie installation right now that tooks a lot of my free time. Convention v3.0.1 support is mandatory there. Also, pre-configured devices are, so I don't use config mode.
That said, I can take care of the #develop-v3 branch for all the parts that do not involve the configuration mode.

[Misiu]

@euphi it would be awesome to have v3.0.1 version released.
I'm looking for a library to build 8 relays and 8 DS18B20 floor heating system and Homie looks very promising - I really like that it is supported by openHAB (finally 😉 ).
If I want to try things out I should try develop-v3 branch?

[euphi]

@Misiu If you use platformio, you can use the #develop-v3 branch with:

LIB_DEPS = https://github.com/homieiot/homie-esp8266.git#develop-v3

[stritti]

Sorry for late response. First of all: thanks for the invitation. I think it is good to have several maintainers to have better continuity. I am not the best C/C++ programmer doing normally Java, but I would like to support the team because I like to have a standard for home automation via MQTT.

Focus on v3.x

I am complete with you: the versions are confusing. We should focus on v3.x.
I personally would like to support ESP8266 and ESP32 in one lib, because I struggle every time on other libs not being compatible. I know, it is an effort, but I think it is not unmanageable.

Roadmap

To prioritize the roadmap, we could use the Project Boards: https://github.com/homieiot/homie-esp8266/projects
There are already two (outdated?) boards. What do you think?

[kleini]

I will use then a mix of devices based on develop and develop-v3 to test both development branches. I will provide PRs for functionality and fixes I find useful. As I am contributor now, please assign PRs to me, that I should review, test and try to get merged.

What about the Git merge strategy? I looked at the v2.1 branch from timpur and I am really confused by all those branches and merges:

I am developer and release manager for more than ten years now. I saw Git merge creating syntactically correct code, meaning it even compiles, but it was semantically wrong. If it is merged syntactically wrong the compiler will tell you. But compiling code, that is semantically wrong is horrible. What do you think about using rebase and fast forward merges only?

[CWempe]

I am not a developer/contributer.
But i think cleaning up the branches would be helpfull for users, too.

It is very confusing with two develop branches and not knowing if any of those two is (almost) "stable".

Is there any progress on this?

[luebbe]

I feel the same. A while ago we agreed on gitter that we would ditch (deprecate) the develop branch after merging everything that is important to develop-v3.
I am afraid, that nobody really has the insight to make these decisions. Or if he has the insight, he doesn't have the time, otherwise it would be done already.

[stritti]

Who could finalize this issue? I have not enough permissions to change The environment.

[euphi]

I propose to set #develop-v3 branch as default as soon as posssible - and to tag release candidate for v3.0.0 - and release v3 some weeks after.

There is no need to maintain v2 anymore - also, I think all important changes in v2 are also merged to v3 (or are not relevant).

@stritti I invited you to the homieiot organization yesterday, so permissions should no longer be a problem.

[stritti]

Thanks @euphi I saw it.
Tomorrow I will start to refactor git. Hopefully everything will work well.

[stritti]

@stritti I invited you to the homieiot organization yesterday, so permissions should no longer be a problem.

@euphi / @davidgraeff sorry but the permissions are still limited. I can not adjust the branch settings:

[davidgraeff]

You are organisation member. I have given you admin rights for this repo additionally. Please don't delete everything xD

[stritti]

Long time requested, now the repository is refactored:

Refactored Repository

• develop: latest development version (moved from develop-v3 which is removed now)
• v2.3: latest version of 2.x (which is moved from old develop branch)
• v3.0: currently branched from develop-v3
• master: merged from v3.0 to be latest stable version.

Some trouble

Because of renaming the branches the PRs have been closed automatically (sorry bothering you):

• Don't run loop if connected to Wifi, but not yet connected to MQTT. #649
• Use recursive config patching #628
• added dependencies for ldf mode off #625
• Added deep sleep support for ESP32 #600
• Fix SonoffDualShutters example #623

Hopefully everything else works as expected.