V2.0 and mega branches too far from each other

[soif]

Dear maintainer(s)

While I'm mainly using the v2.0 (aka develop) branch to develop and push PR to you, I've once switched to the mega branch just to discover features that are still not currently in the v2.0 branch. This should be the opposite. 🌵

So I've made a diff between v2.0 and Mega branch and I've seen a LOT of differences!

As I can understand that ReadMe, Releases Note and versions differ, and that lastest (not merged) commits to V2.0 differs, I can not figure out the large amount of changes made into the mega that are still NOT in the v2.0

So either I still not understand the differences between the 2 branches 👶 (so please clarify), either you really should merge the mega branch INTO v2.0 branch, so that there are no such large divergence as of today.

BTW I saw that there is a conflict to merge between both, but you could at least cherry-pick most of the mega-only commit into the v2.0.

🍻 🍻 🍻

[Grovkillen]

https://www.letscontrolit.com/wiki/index.php/ESPEasy#Version_names.2C_numbers.2C_and_branches

[TD-er]

I agree there is too much uncertainty, bugs fixed in either branch and not in the other. Some overview would be great. On Mar 3, 2018 08:45, "soif" <notifications@github.com> wrote: Dear maintainer(s) While I'm mainly using the v2.0 (aka develop) branch to develop and push PR to you, I've once switched to the mega branch just to discover features that are still not currently in the v2.0 branch. This should be the opposite. 🌵 So I've made a diff between v2.0 and Mega branch and I've seen a LOT of differences! As I can understand that ReadMe, Releases Note and versions differ, and that lastest (not merged) commits to V2.0 differs, I can not figure out the large amount of changes made into the mega that are still NOT in the v2.0 So either I still not understand the differences between the 2 branches 👶 (so please clarify), either you really should merge the mega branch INTO v2.0 branch, so that there are no such large divergence as of today. *BTW I saw that there is a conflict to merge between both, but you could at least cherry-pick most of the mega-only commit into the v2.0.* 🍻 🍻 🍻 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#997>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADk9lmn0V6kjJYGa9Rl-R8wVnDWjLCUkks5takofgaJpZM4Sa0mV> .

[soif]

Why do not simply adopt the convention widely adopted in MOST open source project all over the world?
Two master and develop branches. PR goes to develop ONLY, then develop is regulary merged into master when commits are considered stable enough.

This way developers work on the develop branch, while regular users test the more mature master branch: simple, standard , easy and no conflict between branch

In this goal you would certainly need to:

• rename master to something like v1.4-stable
• rename v2.0 to develop
• rename mega to master
• finally merge all difference from master into develop, to restart clean.
• from now on, make PR and new commits ONLY to develop, then regularly merge it into master
• and insert tags in master and develop like "v2-alpha20180302".

That would certainly be easier for everyone, including beta testers.

This would even allow us to also use the convenient git flow workflow (read this or this if you dont know it already).

What you think ? 😍

[TD-er]

Opinions about branching strategies can be very strong. There have been battles about less ;)
But I totally agree there should be some change in branching. Currently there are developers coding against "mega" and some (including me) against v2.0.
Regardless what's considered to be the best strategy, the current workflow is just wrong.

This one resembles your suggestion I guess:

I guess we should continue to use the "normal"/"dev"/"testing" defines to mark different levels of faith in stability. But that would probably only be used on plugins and controllers.
The core should be the same between releases.
This way we can prevent errors in storage compatibility and forgotten merges.

Last night, I merged about 5 plugins with a major issue, which was fixed in Mega and not in v2.0.
That should not happen and those are very hard to find.

For an "official" release, there should be a window of at most a few weeks between split an release.
But I think we could somehow adopt a continuous release cycle more or less what we're doing the last few months. Although it would be nice to have an official release indicating the big improvements. (and meet @Grovkillen, @psy0rz etc. :) )

[soif]

Yep, the "git-flow" workflow resembles to your scheme, I find it more clear on the graph at:
https://danielkummer.github.io/git-flow-cheatsheet/

But anyway using "git-flow" is not really my point, it would just be an option (that you'd choose to use or NOT) made possible simply by using the standard [ develop and master ] branch naming practice.

You could just stick to a master + develop strategy (PR to dev, merge to Master), and may-be add a develop-plugins branch for the testing ones. You should also definitively rename the current master to something like 'v1.4-current-stable'.

But whatever the naming you finally choose, IMHO mega should be merged into v2.0 in a way or another.

I'm only a small committer, and you are the guys who will decide how you want to organize yourselves, but I've just liked to give you some feedback on how messy and confusing it looks for external guys whoever want to contribute or just test latest firmware released (and so report issues). And also as noted by @TD-er , the current branches just add unneeded work and headache 👶 .

I'm pretty sure it would be a huge improvement for everyone, if you make all of this simplier, whatever the strategy you finally choose 🍺

---

@TD-er : What you mean by :

and meet @Grovkillen, @psy0rz etc.

[TD-er]

@soif At the slack channel, @Grovkillen mentioned it would be nice if we could meet face-2-face.
And @psy0rz and I live quite close to eachother (less than 100 km). So that was once mentioned as an excuse for a "release party" :)

And I think it is great feedback, especially since I spent more than halve the time yesterday on merging + comparing branches, it is exactly the right time to start a discussion about it.

[Grovkillen]

It's my main focus right now, the release party! 😉

[soif]

You're both from Netherland, right? Greeting from South of France 😃

[uzi18]

In my opinion it is better to push into development branch and then after a while of testing, cherry-pick it into stable, but it is sometimes more than one commit to pick .... how to track what is missed?
On the other hand have some problems with git rebase, so I use only git pull, not sure what is wrong, need to try one more time.

Greetings from Poland :)

[TD-er]

@uzi18 I guess it would make things easier for you.
You only have to focus on one base level and thus less issues with Git for the normal devs.

@soif @psy0rz and I both live in the northern part of the Netherlands indeed. @Grovkillen lives in .se :)

[soif]

What a truly European 🏤 dev team 😈 ! Not any Yankee around ?

@uzi18 Cherry-Picking only a few commits, would in mid term returns to the exact same situation : the two branches will end up diverging .

The common practice is that everyone always work and then push to the develop branch; But, then, the maintainer merge the develop branch into the master branch. Often he would choose to merge only commit that are old enough so that he can be confident that they were stable enough whenever no developer have encountered any issue since. Also ANY commit (ie a HotFix) pushed directly to the master branch should immediately be merged into the dev branch at the same time.

Another more sophisticated workflow is to use the "Git Flow" method cited above, but that needs a bit more training for everyone involved.

The opinion of our beloved @Grovkillen ⭐️ and @psy0rz 🌟 would certainly be helpful.

[Grovkillen]

Yes we have a big misunderstanding regarding the branching so a reboot is needed. But not until after the release of 2.0 I vote.

[uzi18]

For now I just trying to give for rules more power and intuitive coding way for newbies.
As You can see every step further we need to fix strange or even never working things (time comparisions).

@soif 1/2 of Europe ;)

[soif]

But not until after the release of 2.0

But what will be the real stable v2.0? 😱

According to the wiki, you says it is the v2.0 branch (ie the master) and that "Mega" is the development version (aka develop), but we most PR to V2.0 while @psy0rz always merge if after some time into mega, while some fixes, are in the meantime committed ONLY to mega.

This the exact mess I'm talking about 😸 😸 😸 😸