How to manage feature changes during release cycle?

[Mike Torrettinni 198]

I hope the title present the question correctly, so here it goes:

 

One of my projects got to the phase where there will be no major yearly releases, anymore. But quarterly or monthly updates. So, no more 6-12 months development of new features and then releasing all at once.

I think this is called sprints...?

 

Anyway, in the past, to avoid multiple branches (1 for bug fixes, 1 for new features), I would only have 1 branch and new features would not be published. Simple, to avoid duplicated bug fixes implementation. New features would be hidden while old release bug fix updates are released, and enabled in menus on new release.

 

But now I will make big changes to existing features. So I need to find a way to manage changing current features and releasing bug fixes before all the new changes are implemented. It's easy when you add new controls (button, checkbox), you have them hidden until release date.

But what if you change the layout or making big changes but are not ready for release when is time for bug updates?

 

I want to avoid duplicating features, views, frames, code and then switching to new ones on release.

 

Is there a way I can avoid all this duplication?

 

Any advice is appreciated!

[David Heffernan 2353]

These aren't sprints. Those are a term used in scrum. You can read about that to learn what they are. 

 

The simple answer is that you need to use branches. Every time you make a release, create a branch for that release. All bug fixes are made on trunk and then merged onto whichever release branches are supported. 

 

This is much simpler and much safer than your current approach. 

[shineworld 73]

I'm in the same situation.
I've solved that using git branches feature.

[Attila Kovacs 631]

Can we see a "branch" example with 10+ projects having own code, shared code, 10+ major 3rd party libs, tons of binary data, whatever I forgot to mention. Asking for a firend.

[Lars Fosdal 1793]

17 minutes ago, Attila Kovacs said:

Can we see a "branch" example with 10+ projects having own code, shared code, 10+ major 3rd party libs, tons of binary data, whatever I forgot to mention. Asking for a firend.

We do that, but we can do that because our projects are inhouse and closely related, and we have control over the release and upgrade cycles, and we always upgrade all apps to using the latest 3rd party libs.

 

But - if there are 10+ projects that are not really related, they would need repositories of their own, and the shared code would need to have a repository of its own.

The question remains whether the shared code should always follow the latest version, or if you pin a version per project and upgrade on need only.

The third party libs dependencies will be a challenge here - especially if there is a difference of version of the libs between the projects.

[Mike Torrettinni 198]

2 hours ago, shineworld said:

I'm in the same situation.
I've solved that using git branches feature.

I do use branches but not that often, so that wasn't my first thing to think about. But it makes sense, a feature changes in it's own branch and when ready merged and released. And all bug fixes that happened meanwhile will be retained in the main branch.

 

What if the bug fix is needed in the feature, screen you have a branch out? In this case you need to implement the fix twice, in main branch to release bug fix and in a branch to not reintroduce bug... how do you handle this?

Edited September 28, 2021 by Mike Torrettinni

[Lars Fosdal 1793]

We use this model. Works quite well.

https://nvie.com/posts/a-successful-git-branching-model/

[Mike Torrettinni 198]

1 hour ago, Lars Fosdal said:

The third party libs dependencies will be a challenge here - especially if there is a difference of version of the libs between the projects.

 

1 hour ago, Lars Fosdal said:

we always upgrade all apps to using the latest 3rd party libs.

Same here. well not always the latest, but all projects always use the same version of  3rd party libs.

 

1 hour ago, Lars Fosdal said:

The question remains whether the shared code should always follow the latest version, or if you pin a version per project and upgrade on need only.

I don't handle this good enough, because shared code is always the latest version and it's annoying looking at old project that should have old share source, but that's rare.

 

What do you mean by 'pin a version per project'?

[Lars Fosdal 1793]

Just now, Mike Torrettinni said:

What do you mean by 'pin a version per project'?

Pinning a version means that you pull from a specific version instead of the HEAD version (i.e. latest)

[David Heffernan 2353]

5 minutes ago, Mike Torrettinni said:

I do use branches but not that often, so that wasn't my first thing to think about. But it makes sense, a feature changes in it's own branch and when ready merged and released. And all bug fixes that happened meanwhile will be retained in the main branch.

 

What if the bug fix is needed in the feature, screen you have a branch out? In this case you need to implement the fix twice, in main branch to release bug fix and in a branch to not reintroduce bug... how do you handle this?

Thus isn't how I do it.

 

I have a development branch. New features and bug fixes go there first. Now, if they are anything other than completely trivial they will be developed on feature branches and then merged back to the development branch. 

 

Then whenever you do a release you branch off a release branch. And then you choose which commits from the development branch need to be merged on to the release branch or branches. 

 

You don't implement anything twice, it's just merges. Obviously sometimes there are conflicts to deal with. 

 

You can also buy books that go into this in detail. 

[David Heffernan 2353]

3 minutes ago, Mike Torrettinni said:

I don't handle this good enough, because shared code is always the latest version and it's annoying looking at old project that should have old share source, but that's rare.

That's very risky for release branches. Release branches are typically meant for bug fixes. Updating shared libraries as you do is likely to lead to new bugs being introduced to your release branches which are supposed to have a reducing bug count! 

[Uwe Raabe 2064]

1 hour ago, Lars Fosdal said:

The third party libs dependencies will be a challenge here - especially if there is a difference of version of the libs between the projects.

That is a common scenario and usually works well. In my case I have about a dozen 3rd party libs shared between different projects, where each references a certain revision. When I decide to update that project to a newer version (not necessarily the latest) this can be done with minimal effort. Repos with inhouse shared code are treated the same way as if they were 3rd party ones.

[Mike Torrettinni 198]

1 minute ago, Lars Fosdal said:

Pinning a version means that you pull from a specific version instead of the HEAD version (i.e. latest)

Hm, not sure I know what you mean exactly.

So, when you commit (or release) main project you somehow note the shared code version. And in the future when you need to go back to this version of main project, you also pull that noted specific version of shared code. Right? Is that manual process?

[Lars Fosdal 1793]

As we've touched on before, @Uwe Raabe , the "fun" starts with 3rd party design time components. 

Maintaining projects that use two different versions of f.x. TMS components is something I really want to avoid if I can.

 

[Lars Fosdal 1793]

9 minutes ago, Mike Torrettinni said:

And in the future when you need to go back to this version of main project, you also pull that noted specific version of shared code. Right? Is that manual process?

TBH, I don't know for sure since I've never used that feature myself since we always use the same version of the shared code for all our projects.  

I'd have to read up on sub-modules and externals to find out, but perhaps somebody else here is using this?

[Mike Torrettinni 198]

16 minutes ago, David Heffernan said:

Then whenever you do a release you branch off a release branch.

Aha, my main branch is always what gets released, so bug and feature branches get merged back into the main and released (well in only rare cases, so far). I never have the need to release bug fix for older version, so never needed to make a release branch.

It's simplified and it works because I'm the only developer on this project.

 

[David Heffernan 2353]

8 minutes ago, Lars Fosdal said:

I'd have to read up on sub-modules and externals to find out, but perhaps somebody else here is using this?

This is pretty simple with git submodules and svn externals. For svn externals you specify the commit that you want to reference, and so when you create a release branch, that commit is captured there. If you update the external reference on the development branch, that won't change anything in the release branch. I believe that git submodules work in the same way, they are a reference to a specific commit in a repo.

[David Heffernan 2353]

2 minutes ago, Mike Torrettinni said:

It's simplified and it works because I'm the only developer on this project.

I don't think it matters how many developers there are. That doesn't change anything. Even with one developer you still need to maintain separate branches for current development and historical maintained releases. I work exactly the same way on my solo projects as I do on my collab projects.

 

I strongly recommend reading up on this subject, you'll get a much better idea than this sort of threaded discussion. Here is a great place to come ask questions once you've read up the subject but I wouldn't recommend starting like this.

Edited September 28, 2021 by David Heffernan

[Lars Fosdal 1793]

Ref. https://nvie.com/posts/a-successful-git-branching-model/

 

We came from SVN, so we had to rework our mental SVN model for git, but once we learned the mechanisms, none of us miss SVN at all.

One of the hurdles was not thinking about master/main as trunk, but as the release branch, and that you did all the work you used to put in SVN trunk, into a develop branch.

Feature branches are really, really helpful - but don't let them drag out too long, or you will likely be facing merge conflicts if you are multiple people working in the same repository.

 

[Lars Fosdal 1793]

3 minutes ago, David Heffernan said:

This is pretty simple with git submodules and svn externals. For svn externals you specify the commit that you want to reference, and so when you create a release branch, that commit is captured there. If you update the external reference on the development branch, that won't change anything in the release branch. I believe that git submodules work in the same way, they are a reference to a specific commit in a repo.

They are similar, but not identical it seems - judging by this: https://github.com/stettberger/git-external

[David Heffernan 2353]

2 minutes ago, Lars Fosdal said:

One of the hurdles was not thinking about master/main as trunk, but as the release branch, and that you did all the work you used to put in SVN trunk, into a develop branch.

This works fine. The key point is to keep separate branches for development and releases.

[Mike Torrettinni 198]

21 minutes ago, Lars Fosdal said:

TBH, I don't know for sure since I've never used that feature myself since we always use the same version of the shared code for all our projects.  

I'd have to read up on sub-modules and externals to find out, but perhaps somebody else here is using this?

Thanks, I didn't know about git submodules, which seems what I could use:

 

"Git submodules allow you to keep a git repository as a subdirectory of another git repository. Git submodules are simply a reference to another repository at a particular snapshot in time. Git submodules enable a Git repository  to incorporate and track version history of external code."

[David Heffernan 2353]

Read up on git submodules properly, and read about the potential pitfalls. Just like svn externals they sound compelling but you can easily get into a bind with them.

[Mike Torrettinni 198]

I think there is just 1 question that I'm a still unsure how to handle: what if there is a bug in the part of the code that is being changed in a branch?

You guys probably have short lived branches, I don't ...  I can redesign a feature and release it in a month or more. What if there is a bug in this feature, I fix it in main branch to have release for customers, but the old code is in the branch I'm currently working on.

 

So, I do need to patch this branch,too? There is no other way?

[David Heffernan 2353]

3 minutes ago, Mike Torrettinni said:

what if there is a bug in the part of the code that is being changed in a branch?

Fix it in development branch, and then merge on to feature branch and release branch,