Peertube: Question about git workflow

[kimsible]

I may be wrong, I don't have all the history of the PeerTube project but I wonder if a workflow with feature branches instead of having a default develop branch would be better.

This way, the fixes could be merged as a patch to master without waiting a new major or minor version.

What do you think about it ?

[rigelk]

Could you describe your workflow in more detail? There are multiple branch-based workflows.

This way, the fixes could be merged as a patch to master without waiting a new major or minor version.

We are actually using a branch-based workflow, but develop acts as a buffer branch. We only backport security fixes to master in-between releases.

Why use an intermediary branch like develop before "releasing" a version by adding its commits to master? PeerTube is a web service with multiple components; testing it for regressions requires a bit more work than our test suite allows. Typically this testing requires some manual testing before release by checking live deployments, and a release candidate. Releasing feature branches would involve a lot more steps than just the git merge.

Merging often on develop also helps keep PRs functional, and helps reviewing them for regressions and conflicts beetween PRs.

[kimsible]

Ok thanks for taking time to explain.

Why use an intermediary branch like develop before "releasing" a version by adding its commits to master? PeerTube is a web service with multiple components; testing it for regressions requires a bit more work than our test suite allows. Typically this testing requires some manual testing before release by checking live deployments, and a release candidate. Releasing feature branches would involve a lot more steps than just the git merge.

I understand but tests for regressions can also be done on a feature branch ?

Maybe the point is not the workflow itself but to consider not only the "security fixes" to be mergeable into master. For the UI, sometimes it's hard to say what is a fix or not, but in my point of view, fixes which does not touch the entire UI or a re-design could also me merged to master.

It's not to say all we done these last days about UI should have been merged but maybe some ones.

In my experience, front-end projects I contributed was more fluid and clear with a 'basic feature branch workflow" (sorry I don't have the exact name). The principle was to work only on small features or fix when the app was considered as "stable", especially to not create too much regression.

[rigelk]

front-end projects I contributed was more fluid and clear with a 'basic feature branch workflow"

Maybe I can go look them up?

The principle was to work only on small features or fix when the app was considered as "stable", especially to not create too much regression.

We could try a feature branch scoped to specific parts of the application (light componenting and style fixes for instance). But there is an inherent added maintenance cost to releasing more often, and we have to keep it in check too, so this wouldn't be feasible on many branches - unless I misunderstand your point, ofc.

[kimsible]

Maybe I can go look them up?

By contributing, I also meant close source projects :-(

But I have some web service in mind:

• https://github.com/flarum/flarum
• https://github.com/NodeBB/NodeBB

And also many Javascript frameworks.

We could try a feature branch scoped to specific parts of the application (light componenting and style fixes for instance). But there is an inherent added maintenance cost to releasing more often, and we have to keep it in check too, so this wouldn't be feasible on many branches - unless I misunderstand your point, ofc.

Yes it could be a solution, and I understand, the releasing process can take lots of time.

I don't try to invalidate the current workflow for the front, it also exists for many reason of a backstory project, just try to question it if something can be improved.