I have been following the messages about 4.0 alpha/beta stuff with interest, expecting to get around to testing some day.
I just did a git remote update, and was surprised to find that master, which had previously been the stable branch, now contains 4.0beta (loosely speaking). I must have missed the announcement of the big merge from develop, which I consider to be of huge import. I spent a bit of time digging through to find out if there were any changes to 3.8 since my last update, and concluded no. I realize opinions differ, but I think the master/develop scheme is awkward and difficult to deal with. Yes, I realize that new unstable stuff goes on develop, and at some point develop is merged to master. But, I'm trying to be on 3.8, and get bug fixes, and not jump to 4 yet, until I can do a build/test and try the simulator. Part of this is that I'm running NetBSD rather than Linux, which probably nobody has tested on, and probably it is fine, but I am basically doing the staging/qualify/upgrade normal IT change management thing, which I see as well within normal for anyone who is trying hard to avoid trouble. With the master/develop scheme, there are multiple serious problems: I was trying to follow 3.8 stable, but if I "git pull", I jump branches (even though we haven't had a release as far as I can tell). If I want to follow 3.8 stable whether or not 4.0 is released, because I want to choose when to jump branches, that's not just not automatic, it's pretty difficult. There is no mechanism to apply a bugfix to 3.8, as of the instant that develop was merged to master. (Yes, I get it that a branch could be created retrospectively. But the master/develop scheme militates against that happening.) In contrast, the stable/master scheme is much easier to deal with: master has new code on it (exactly like develop is today) each stable branch has a branch, e.g. "stable-3.8", and fix commits are put on it. They are merged to master usually, just like master commits are merged to develop usually (or cherry-picked from there). when it's time to start a new stable for 4.0, a stable-4.0 is branched off master. people who want to switch from 3.8 to 4.0 do "git checkout stable-4.0". People who aren't ready yet don't. There is no magic and it is really obvious what one is on when typing 'git status'. the downside is that people that pay zero attention and just git pull remain on the stable branch they were on. (I actually think that's a good thing.) The stable-3.8 branch remains indefinitely as one that could be updated with a fix, and can easily be accessed by name. So this is a long way of saying that today the master/develop felt extremely awkward, for no real overall benefit, and I'd like to suggest changing to stable/master. Now, I realize that a lot of people are using git to get code, when those people do not necessarily understand git. I wonder if the master/develop scheme's main point is that a naive checkout gets one the most recent stable. So maybe getting that benefit without all the pain of master/develop would be: develop: new code codes here stable-N: branched off develop for new branches, and each one gets bug fixes master: the highest stable-N is merged to master, so that master is always the most recent version of the most recent stable. The only point of master, and the only use, is people that do checkouts and don't understand git or weewx well enough to choose a stable branch explicitly. (IMHO, these people should be using distribution packages, not git.) Thanks for listening to me rant, Greg -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to weewx-development+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/rmiblphyuuz.fsf%40s1.lexort.com.
