Flash! Ah-aaaaah! Geek code v 3.12 {      GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*      Weapons extension: ma- k++ F+2 X }

Let them boot their desktop from the cloud without internet :suss: Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

When to merge two specific branches is a policy decision for your lead/project manager. In my case, I don't have to deal with QA, Release, or Code Freeze, but that's just a peculiarity of being a tools dev in the game industry. But, here is how I would do it if I were asked to: Master: aka Develop. It is by and for the developers, and they control when things get merged into it. I see no reason why this branch should ever be frozen, but it should also never be broken (that's what feature branches are for). A dev should ALWAYS rebase their feature branch on master and test it before pushing to master/submitting a pull request. Feature branches: Created and deleted by individuals/teams as needed. Merged into master when the feature is "done" (ready for validation, QA, etc). QA/Freeze: branched off master from whatever commit is determined to be a release candidate. Bugs should be fixed on this branch and those fixes should be merged back into master asap. Release: QA/Freeze branch when it's deemed ready to ship. The branch name should probably include the version number (eg: "release_3-0-0"). Start a new QA branch for your next RC. Other branches (Production, Hotfix, etc) are basically just special cases of the above.

Once again, with the security agument reason for upgrading. No one is secure anywhere, Infact it wont be long before XP will be more secure, as it will not be targeted anymore. The only argument, I would use is that if you want to continue using IE, then you need to upgrade, because MS have delibritly gone out of thier way to not allow modern IE on XP. Just use CHrOme iinstead. And don't listen o the secruity rhetoric.

As an older embedded developer I feel your pain. The technologies that drive the need for "big iron" when it is not needed have hardware and software costs that go right to the bottom line. Unfortunately many new engineers only know how to approach a problem with a sledgehammer. Today's students would be well served by a semester or two doing projects for PICs or 8 bit microcontrollers no matter what field they go into.