`stable` branch
jeremypoulter opened this issue · comments
There are 15 changes on the stable branch that are not on the development branch, are any of these needed? If so can they be merged? Also can we remove the stable branch from this repository and use the stable branch in the OpenEVSE fork as the official stable/release location?
Alternatively maybe we switch both repositories to use main as the default branch name, this repository is the main development repository and the OpenEVSE repo deales with building for specific hardware/territories, etc
I agree that the stable branch should be archived. I am thinking of renaming it to stable_archived. Sorry, I don't know how you guys manage your downstream branches. How do you guys separate out the releases, given that there are different variants? I don't even know who releases what for which region. The whole idea of my repo is to provide a codebase whereby anyone can configure the firmware to their own needs. It isn't just for whatever hardware is currently being offered by openevse.com and its affilliates. That's the job of the OpenEVSE repo. I may make changes sometimes that you guys don't agree with or want to use, and it's very constraining to have to worry about possibly breaking downstream code. For instance RAPI was first implemented in a vacuum, and now that we have client code, it's proving to be rather inefficient, requiring far too much polling in order to get the current state. I guess I could silo cutting edge stuff in a separate branch, but I really don't have time to be managing separate branches, and figuring out what to merge between them. The whole reason I started the development branch in the first place was so that it could be the place to put experimental code, but over time, the stable branch died, and now, it seems the development branch is turning into the de-facto release branch. This is not the intent of this branch. It's for testing out new code and ideas. I want to help you guys, but at the same time, I don't want to get locked into writing code that's constrained by whatever your specific WiFi implemention relies on.
Thanks for the thoughts, basically with all the Platform IO work and GitHub Workflows we now have all the different builds coming from the OpenEVSE fork and have been pulling changes from the development branch as needed, so from our POV we have that isolation there and can manage merging any breaking changes as they come up. So I think that model basically matches what your thoughts are. You can apply changes to the development branch and then we can pull any changes as needed.
The main reason for raising this issue was to check that the changes made on stable were no longer relevant and if we could harmonize the branch names between the two repos, I could of course change the default branch on the development but that is not ideal, and with it as stable as it is now GitHub shows that the branch is 100s of commits ahead of your stable branch. Switching both to main is probably the easiest, but up to you not a huge issue just a matter of aesthetics really.
OK, I renamed my stable branch to stable_archive. The new default branch is master, and I'll make all of my preliminary changes in development, as before, prior to merging into master. I'm closing this now, but if you have any disagreement, feel free to reopen or comment
Sounds good, thanks for your support