Branching Strategies #823
Replies: 9 comments 11 replies
-
|
Initial thoughts. I haven't watched the videos yet. My main concern is release stability. The first three approaches don't even have a develop branch. That means that when we release something (create debs, etc.), main effectively gets frozen in those debs, etc. That sounds fine, but AFAIK, packagers don't use our debs, etc. they make their own whenever they get around to it. IIUC, this has a few implications: If we continue development, then packagers get whatever they get depending on when they get it, not on when we release it. This might mean that 0.96.1 on Debian might be dfferent than 0.96.1 on Fedora... That way leads to madness, especially for people like me trying to do support, but also for developers trying to figure out what a line number in a traceback from an issue report actually refers to in the version of the code they're looking at. Currently, I'm not sure how it works, but I think that things can be added to develop whenever someone thinks they're good enough to share with the rest of the team. This does not imply that they are good enough/ready/agreed upon to be included in the next release. That can be decided later when we intentionally create a release. If we go with any of the first few options presented above, we lose the buffer that develop provides and we lose the ability to add new features and fixes that are still tentative or maybe for a release that's further out. These concerns need to be addressed by whatever strategy we adopt. And there's the significant issue that any changes to our build/release strategies have to be coded/configured by someone. Who, besides @BlueDrink9 (who probably doesn't want to do that work) knows how to do that? Maybe @sebastiansam55 does. @Elliria is learning fast, but I'm not sure she's ready for this yet. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the initial feedback. I'd love to hear more after you've watched the video(s). Releases shouldn't be a problem in any of those scenarios, because they're created with tags in all branching strategies regardless of how many branches exist. My main concern is that the branches are in disarray and it's likely to only get worse. I've contributed to some of that disarray and am likely to continue to do so when we need to make changes to more than one branch. When I've turned to others for advice on how to do that in a tidy way, I keep getting the same answer and that's to simplify things - most specifically, the branch strategy. They don't actually tell me how to clean up or "properly" use what's there because they don't feel that we should be using it. My hope is to reach a point where it's only necessary to contribute content to one branch (the develop branch), but that's not likely to be possible with this branching strategy. There will inevitably be times when the same content is also needed in one or more other branches, as we've been seeing with some of the updates we've been doing. When it comes to making the same change in more than one of (or all three of) our long-running branches, would you like me to continue to add to the branch divergence by copying known-good contents from a file in one branch to the same file in another branch in separate commits and pull requests? Or do you have a different approach you'd like me to use? |
Beta Was this translation helpful? Give feedback.
-
|
I'll watch the videos when I get a chance. Hopefully some or all of my concerns are non-issues. Since these concerns are almost completely generic, I'm sure they can be addressed. Given my lack of experience with git and GitHub, I'm not asking you to do anything. I am concerned that unnessary complexity is being added by the way we're doing things now and I want to make sure any changes we make actually make things better without creating new problems that might be worse. I do not consider beta as a valid branch except when a new release is immanent, so I don't want anything done to it when it's not a proposed release under final testing. That leaves us with two branches, main and develop. Apparently, we can't delete beta when it's not in use (which is what I wanted to do). |
Beta Was this translation helpful? Give feedback.
-
|
No hurry. Just beware that things will get messier before they get tidier. Although you don't consider beta to be a valid branch, it has been basically forced upon us by the structure of our branching strategy, so it's a necessary evil. As such, there are things that will have to happen to it, because the fact that it needs to be there means it gets used. It's currently behind on the action versions that I just updated in the develop branch and will need to have that done to it as well. This is because those actions will also be run on the beta branch. Ditto for the master branch. So, I'm back to my original question: When a change (like a version update) needs to be made to the same file in more than one branch, would you like me to continue to add to the branch divergence by doing the appropriate edits from the list below in separate commits and pull requests?
|
Beta Was this translation helpful? Give feedback.
-
|
I err on the side of less git stuff, because I don't have much experience with it. At most I would have a master/develop branch and even then, what % of users are installing autokey directly from master branch? I would assume 99% would be installing from their package manager of choice so at that level there isn't even much reason to keep master "stable/clean" if we use git tags to tag releases. What's the current status of the beta branch? They were beta of the .96 release it seems like? So they could be deleted since .96 has been released? |
Beta Was this translation helpful? Give feedback.
-
What will happen if I go for it and submit pull requests to, for example, do the same update to the activities in the beta and master branches as just got done to the develop branch? Will those be cancelled, just sit there, or get approved? Or would you rather I hold up on stuff like that until further notice after you get more input from others? |
Beta Was this translation helpful? Give feedback.
-
Thank you for that. I agree, and I think @josephj11 does, too. Although, then again... I think even that's too much and am really liking the feature branching strategy above as the gentlest one.
No idea, but you're probably right that most of them are grabbing the AutoKey packages provided by their operating systems.
@BlueDrink9 said we shouldn't delete beta because workflows make use of it. Also, if you look at our branches both develop and beta are based off of master and are independent of one another. As a result, they're each ahead of and behind master in differing ways and each seems to have things the other doesn't. Some of what each of them has (and no longer has) may be "good stuff" and not something to be thrown away, but someone will have to look it all over and figure that out one file at a time. It will not be a pretty job. I would have thought that beta shouldn't have anything in it that isn't in develop, but develop would be expected to have some things that aren't in beta. The way I envision Git flow branching working, if our three long-running branches must continue to exist, would be for beta to be based off of master and for develop to be based off of beta. All development would only ever happen to develop from pull requests from temporary branches that get deleted afterwards. Only production-worthy changes in develop would go onto beta via pull requests. That way, beta wouldn't contain anything that's not already in develop, develop would contain everything that's in beta and also things that either aren't up to snuff yet or at all and/or aren't finished. That would make comparisons of the two branches much gentler. I'm still unclear as to the purpose of master or how it would fit into this scenario in any useful way, so I'll just figure that it gets to sit there looking pretty. |
Beta Was this translation helpful? Give feedback.
-
I wanted to delete the beta branch as well until @BlueDrink9 told us not to. Unless we use it as "next" release (not specifically a beta), I would leave it untouched until we have an actual need for a beta of the next release and, ideally, I would "copy" all of that new release onto an "empty" beta so there is no question of syncing anything. If we go with @Elliria 's suggestion of develop->next->main that would require that fixes to the beta or main would have to be applied first in develop (if possible), then migrated to next and finally, to main itself. That would keep all PRs one way with the required discipline, but that sounds like a lot of work. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not actually suggesting or recommending master <-- beta <-- develop, but am seeing it as the least-evil way of restructuring the master <--> beta <--> develop <--> master that we currently have), since it would then mean that data travels in only one direction, making it easy to know where a change needs to happen and making comparisons between branches much easier. As for what I'd recommend, I'm convinced that feature branching is the way to go and that master <-- temporary feature branches is the gentlest structure. |
Beta Was this translation helpful? Give feedback.
-
|
Forgive me for not having had time to watch those videos yet. I'm not concerned (much) about users installing from the master branch directly. I am concerned that distro packagers will build/install from main. If we use release tags (which I don't know anything about yet), will a packager accessing main reliably get the version of the code that we intended to release or will they potentially get changes that were made after the the release was tagged? The latter is what I want to preclude. @Elliria At first, your idea of putting beta between main and develop did∕n't make any sense, but I think if we rename it from "beta" to "next" or something similar that does not directly imply that it's a "live" beta release, then it makes perfect sense. Here in NY, we have ridiculously complex and specific zoning laws and building codes when you want to build a house and really high taxes. We designed a house when we really wanted a couple of small cabins and no matter what we did we couldn't get the cost down anywhere near what we wanted. The laws blocked us. Later, I looked at a piece of land in West Virginia. The taxes sounded similar until I found out that the figure quoted was for a whole year and not for a month! As for zoning/code compliance, I was told "Well, you have to live in it." That was it! The moral of this aside is that both extremes are a bit much to deal with and we should figure out the right mix/level of structure for our project. We have to maintain release control/consistency, but AutoKey is not a mission critical application, etc., so we don't need any rocket science or additional complexity to assure that nothing can ever go wrong. I definitely don't want to stay on "method 5" for which the recommendatiion was, "run the other way" if we don't have to. In this vein, @Elliria and @sebastiansam55 - "you have to live in it" as developers and unless I really object to something, I'll merge (or agree with you to merge) anything you ask me to once I understand what it is at a very basic level. I'm not qualified to review most things line by line, etc., but I'll take a look whenever I can... |
Beta Was this translation helpful? Give feedback.
-
|
I would think that most package maintainers would find our Releases page with download links or would look for the tags in our repository to build from. We're also working on gradually improving our documentation, which will be helpful for them if they read it. Last, but not least, we could do outreach to any maintainers who we're aware of if there's a change. |
Beta Was this translation helpful? Give feedback.
-
|
The beta name is actually fine as it is, since it's an industry standard and is universally understood to be a new, experimental version that's believed to be good, but requires further real-world testing to be sure. Since only solid code goes into a beta, it stands to reason that, regardless of whether its code is tagged as an official beta release or not, anyone could (and should be encouraged to) build the beta branch code at any time and give it a whirl to try out what's currently being worked on. Its name lets them know that. Also, the beta branch gives the AutoKey team the ability to point users to it as a source for code that provides specific features or solves specific problems that haven't yet been implemented in current official releases. So, if a user is in a hurry for [insert feature or solution to problem here], they can try the beta. They could also live dangerously and build from the develop branch at any time (if building even works), but they'd be taking their chances with code that's not necessarily good yet and/or may be unfinished, and we definitely wouldn't want to encourage that. |
Beta Was this translation helpful? Give feedback.
-
|
From what I've been able to figure out so far, this is a very basic summary of our branching/workflow/release strategy (corrections are welcome):
|
Beta Was this translation helpful? Give feedback.
-
|
I was definitely partly responsible for creating this mess. I want to get rid of develop as soon as we have extracted everything useful from it. I don't understand git tags very well, but if they do what I think they do, we may be able to replace develop and beta with appropriate tags on master. Its sounds so much simpler. |
Beta Was this translation helpful? Give feedback.
-
|
The branches have been that way for a long time. We did make some commits to the master branch that we shouldn't have, but live and learn and it will be cleaned up. Git is pretty simple under the hood. It's a collection of moments. Every commit is a moment in time that's represented by its commit ID. If you know the ID, you can use it to visit the code in that moment in time. Tags are labels that you can put onto any commit to make it easy to find (instead of having to remember a commit ID). You can use a label to visit the code in that moment in time. That's it in a nutshell. One of our workflows watches for tags with the
I'm not sure what, if anything, happens if such a tag were used on the develop branch, but I think it just wouldn't be done. |
Beta Was this translation helpful? Give feedback.
-
|
That makes it very clear. Thanks. How do merges fit into this explanation? Are they just "importing" commits from another branch? |
Beta Was this translation helpful? Give feedback.
-
|
In git (locally on your own computer):
On GitHub, that's simplified or complicated (depending on perspective) a bit, because I'm pretty sure that every merge is a commit regardless of circumstance. |
Beta Was this translation helpful? Give feedback.
-
This is an excellent overview Eliria, and matches basically exactly what I set up beta for. It served its purpose well for getting the massive overhauls of 0.96 over the line, but you could definitely delete it if you wanted to and don't anticipate a need for pre-releases. |
Beta Was this translation helpful? Give feedback.
-
Fantastic. Tiny correction: not always a fast-forward merge, you can explicitly request with There's also rebasing, which is closer to a fast forward but for diverged branches. A bit more complicated, probably don't need to pay attention to it |
Beta Was this translation helpful? Give feedback.
-
I've been trying to learn what I can about branching strategies in an effort to understand how our branches work. As part of that, I visited the GitHub channel on IRC. They recommended that we switch to what I later found out is known as the feature branching strategy and it sounds like it would be a very good idea. A bit of poking around online to get more information on how that works turned up this breathtakingly-awesome video on branching strategies from a man named Victor: https://www.youtube.com/watch?v=U_IFGpJDbeU
These are the six strategies described by Victor, listed in frustration order, from the least frustrating (1) to the most frustrating (6) and you'll see where our project falls in the list:
Victor's recommendation for branching strategies:
Alas, we use number 5 - the Git flow branching strategy, which is one of the two most frustrating strategies on that list. Not only that, but we don't quite use it as described. We have three long-running branches (master, develop, and beta) and a few feature branches. Unlike the standard structure for this branching strategy, although our develop branch is based on the master branch, our beta branch is also based on the master branch instead of being based on the develop branch as it should be, which makes them independent of one another and causes them to go in completely different directions. We then use the feature-branch or forking strategy to make changes to each of those long-running branches rather than committing to them directly. We also have what's been referred to as Continuous Integration (CI), but which is actually Continuous Deployment (CD), provided to our project by our beta branch that makes it so that tagged releases that are merged into develop, beta, or master will automatically be built.
The folks on IRC feel that we should be using the feature branching strategy, which is exactly what Victor recommended above. The IRC folks also feel that our CI/CD should be provided by the master branch instead.
I'm thinking that both Victor and the folks on IRC are making a lot of sense. I'd love some feedback on it all.
Beta Was this translation helpful? Give feedback.
All reactions