3 ms·

People actually allow this!?

justinclift 6y ago
It's a standard practise: 1. Create a bug fix on the main development branch. eg "master" or equivalent. This ensures the bug is "resolved" for all new builds and future releases. 2. Apply the fix to the supported release branches. eg v3.12.x, v3.11.x, etc. This ensures the bug is "resolved" for all new point releases created from those release branches. eg v3.12.1, v3.12.2, etc.
- mgkimsal 6y ago
  I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and you're expected to take just those issues from 'develop' (or somewhere) and get them over in to a 'release' branch of the current released code. I now tend to keep local branches of anything I worked on for months, because 4-6 weeks after it was approved/merged (and deleted) in to 'develop', I may have to also do a 'hot patch' on to a release branch, and cherry picking is the proscribed way of doing it.
  - justinclift 6y ago
    That sounds fairly disorganised and nightmare-ish. In practise though, does it work well?
    - mgkimsal 6y ago
      I think it possibly did a few years ago. There's a lot of 'tribal knowledge' stuff, and none of these practices were explained when my team (another... 8ish people) were added to the current team months ago. I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.
- secondcoming 6y ago
  Oh right. My reading of parent was that commits on one dev branch were being cherry-picked for use on another dev branch.
sangnoir 6y ago
YES! Not everyone has the luxury of evergreen continuous deployments onto their own infra. It is quite common for enterprise software that runs in clients data centers to splinter/branch in this way - since they usually want to manage the risk by staging specific versions of your software for testing before going live. They may consider some of your new features on the main branch as too risky, but still want you to backport fixes to their release branch

It's a standard practise: 1. Create a bug fix on the main development branch. eg "master" or equivalent. This ensures the bug is "resolved" for all new builds and future releases. 2. Apply the fix to the supported release branches. eg v3.12.x, v3.11.x, etc. This ensures the bug is "resolved" for all new point releases created from those release branches. eg v3.12.1, v3.12.2, etc.

mgkimsal 6y ago
I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and you're expected to take just those issues from 'develop' (or somewhere) and get them over in to a 'release' branch of the current released code. I now tend to keep local branches of anything I worked on for months, because 4-6 weeks after it was approved/merged (and deleted) in to 'develop', I may have to also do a 'hot patch' on to a release branch, and cherry picking is the proscribed way of doing it.
- justinclift 6y ago
  That sounds fairly disorganised and nightmare-ish. In practise though, does it work well?
  - mgkimsal 6y ago
    I think it possibly did a few years ago. There's a lot of 'tribal knowledge' stuff, and none of these practices were explained when my team (another... 8ish people) were added to the current team months ago. I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.
secondcoming 6y ago
Oh right. My reading of parent was that commits on one dev branch were being cherry-picked for use on another dev branch.

sangnoir 6y ago

YES! Not everyone has the luxury of evergreen continuous deployments onto their own infra. It is quite common for enterprise software that runs in clients data centers to splinter/branch in this way - since they usually want to manage the risk by staging specific versions of your software for testing before going live. They may consider some of your new features on the main branch as too risky, but still want you to backport fixes to their release branch