TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.

I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.

FF to today:

- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"

And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.

Some people are really getting high on this Agile shit. Probably because they learned some new bullshit bingo phrases - and it suits them: lots of vapory talk and expensive meetings and others will have to do the work anyway, while they can circlejerk on how to have shorter iterations to improve the time to market, increase the business value, inspect and adapt to faster deliver a minimal viable product - yeah, do the agile transformation, update to the digital age, you noobs. Throwing around some catchy phrases will let you compete with Google? Maybe need some blockchain or machine learning?
While you are clustering your post its, the coders who keep the ship afloat, sit in their legacy code base that's so bitrot they are mainly doing bugfix releases without a single feature for three fucking years. Consider this.

i asked my senior "why we need a develop branch" and his reply was "-_-" , literally an emoji.

Ok ,well this might be a stupid question, but i have been in this organisation for 6 months and all this time these guys have not been able to make a proper release. either they miss commits while cherry picking, or they end up reverting stuff, or they are delaying the releases due to QA disapprovals, backend issues or management issues.

i proposed a simpler vcs :

1. `uat` is the source of truth
2. for every release we create a temporary branch `release-x.y.z` from `uat`
3. then we develop every feature in a branch cut from `uat` as `feat-abc`, code in it , and merge it back to `release-x.y.z`
4. finally we merge `release-x.y.z` into `uat`

where is develop branch supposed to be cut?
which branch is supposed to be cut from develop?
which branch is supposed to merge into develop?
where is develop supposed to be merged?

no one has answers to these fucking questions. but still they wanna confuse the whole team of 15+ android and ios devs about how to use which procedure

fml :/

Finally finished the longest ticket I've ever worked on in my life. The ticket title and description was a pretty simple and straightforward one: "Upgrade from PHP 7.4 to 8".

If it was only so simple in real life. Our application is mostly done with API Platform framework, which is based on top of Symfony framework which is based on top of PHP language.

Once I did PHP 7 => 8 upgrade I needed to upgrade API Platform 2 => 3. But of-course that couldn't have been done as before that I needed to upgrade from Symfony 5 => 6.

This all was literally an equivalent of touching into a wasp nest - it took me a bit over 5 months and 800 hours of work and there was literally not a single source file left untouched.

In the process of all of this I've ran into literally dozen undocumented feature-breaking changes, broken backwards-compatibility promises and inside out architectural changes - from both the frameworks and the language itself.

Upgrading just one major version of anything SHOULD NOT be so hard. And to top it all up just to think I will need to do this again in a year or two..

Experiences like these really set my hate for time-based model of releases and the state of today's development in general.

I work on a team project for a test and maintenance course in University. We agreed as a team to adopt a git infrastructure that would prioritize the stability of the master branch at all cost by only updating commits up to the next stable point and tagging every single release. We have a long polling development branch to prepare our releases and we create feature branches for the tickets we need to resolve. I even wrote documentation to make sure that we don't forget and protected the master branch on gitlab from direct modifications.

Can someone fucking tell me how one of my teammates managed to fuck over all of this and work on an unfinished feature straight on master?

N.b. I know that he probably edited straight from gitlab's online text editor because they have a big where they don't restrict modifications on protected branches.

I'm in a team of 3 in a small to medium sized company (over 50 engineers). We all work as full stack engineers.. but I think the definition of full stack here is getting super bloated. Let me give u an example. My team hold a few production apps, and we just launched a new one. The whole team (the 3 of us) are fully responsible on it from planning, design, database model, api, frontend (a react page spa), an extra client. Ok, so all this seems normal to a full stack dev.

Now, we also handle provisioning infra in aws using terraform, doing deployments, building a CI/CD pipeline using jenkins, monitoring, writing tests, building an analytics dashboard.

Recently our tech writer also left, so now we are also handling writing feature releases.

Few days ago, we also had a meeting where they sort of discussed that the maintenance of the engineering shared services, e.g. jenkins servers, (and about 2-3 other services) will now be split between teams in a shared board, previously this was handled only be team leads, but now they want to delegate it down.

And ofcourse not to mention supporting the app itself and updating bug tickets with findings.

I feel like my daily responsiblities are becoming the job responsibilities of at least 3 jobs.

Is this what full stack engineering looks like in your company? Do u handle everything from app design, building, cloud, ops, analytics etc..

Hey @dfox , after using this awesome app for some time now I thought about Posting some feedback about some stuff which may can be improved in future releases:

Maybe it would make sense to seperate the notifications in two areas: one area for your received likes and one area for comments made on your posts or posts you comments on. I often find myself not seeing when someone commented on a post because of the many like notifications.

Speaking about the likes I sometimes click on the Username to see who liked a post. If you don't hit the username you are taken to the post instead of the profile. Maybe it would make sense to make the username a little bit bigger or give it some button like layout to make it easier to click, because I often find myself not hitting the username correctly.

Dark Mode is a great Feature, but it would be even better if you could choose when to use darkmode and when to use lightmode based on time maybe, so that those two themes automatically switch.

These are just my 2 cents, which in my opinion would make the app even better than it is and which you may consider in some future releases.

All in all I really like this app and the Community is great, so thanks for creating it. :)

is it necessary to have cherry picking a part of git branching/release process?

we have 3 branches : develop, release and master.

currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.

so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :

1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.

2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x

3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release

4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.

so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.

for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.

what do you folks suggest?

I've been using boomplayer for years now, and I only recently observed that its notification panel has controls for toggling repeat/shuffle/single state. With bated breath, I clicked on it, half expecting it not to budge. But, impressively, it did

It got me thinking about the devs who worked on it and how much their manager would've insisted the app cannot be released without this *crucial* feature, when in reality, it's fringe and 1% of their (in most cases <5k) user base will ever notice it or be bothered by its absence

Now, I'm not advocating for incomplete releases. I'm just saying it's unnecessarily pedantic for management/product owners to double-down over flimsy stuff

Question about managing git branches.

For releases, we branch develop (the main branch) into a release.version branch in which we bump the version and do any last minute bug fixes for issues found in testing.

After the release we need it back into the main branch as well as master.

But also we keep the branch as well in case we need it such as for a hotfix release.

Is keeping it right though?

General issue on my team I feel is nobody deletes their feature branches after they are done and merged into the main branch. I think there is a feature in most Repos where it can auto delete these branches when a PR is merged.

And well branches themselves (at least the HEAD) are sort of just bookmarks. All commits can be accessed by their hash and basically is a full snapshot of all the commits that upto that point that it was based off of?

So you could just tag the last commit in the release branch with release.version and delete the branch itself? And that I think is the correct, normal way?

Not sure how to explain this to my boss or team as they aren't big on technical details...

Juggling between multiple feature releases is a difficult task but I would choose that anytime over doing no work the entire day.
P.S. Managing each features individual branches is a task in itself too

Microsoft rep on Microsoft Comunity:
"Unfortunately the option to Find and Replace is not available in OneNote 2010. If this is a feature that you are looking for in future releases of OneNote, be sure to send your feedback."

Huh? Now look at the OneNote manuals entry for search and replace: tinyurl.com/zdynk8o