Workflow and versioning for bug-fix and security patch

[ctmbl]

    This PR also arises an important question: in such cases where we found a vulnerability and want to patch it, shouldn't we release a `v0.1.1` rapidly to patch the vulnerability on the real website or should we wait for `v0.2.0`.

In the case we want to release v0.1.1 should we:

• A: merge this PR in main and release previously merged PRs (from v0.1.0) with it
• B: merge on a specific branch (let's say released) which is based on v0.1.0 and then merge release into main?

Following git log --oneline ... format:
A:

* (main, v0.1.1) this PR
* commit
* commit
* (v0.1.0) Bump to version 0.1.0

B:

* (main) Merged with `released`
|\
* | commit
* | commit
| * (released, v0.1.1) this PR
|/
* (v0.1.0) Bump to version 0.1.0

Originally posted by @ctmbl in #51 (comment)

[amtoine]

from @atxr

This is a very good question and my answer to this is:
image

This is based on the git flow you shared to us few month ago
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Hence, if we want to use this we have two issue to address:

• We currently use the main branch as develop branch.
• How to redesign our whole git tree, isn't it too late?

[ctmbl]

please edit your message to embed the image linked by @atxr

[amtoine]

and my answer

@ctmbl

This PR also arises an important question: in such cases where we found a vulnerability and want to patch it, shouldn't we release a v0.1.1 rapidly to patch the vulnerability on the real website or should we wait for v0.2.0.

In the case we want to release v0.1.1 should we:

• A: merge this PR in main and release previously merged PRs (from v0.1.0) with it
• B: merge on a specific branch (let's say released) which is based on v0.1.0 and then merge release into main?

i would say B is great to isolate this patch from the commits merged in partial release PRs, i.e. PRs being merged in between two releases.
and A is great if we want to add the other features as well, here that would be 392befa..6d7a9f6 🤔

maybe B is better to have rapid security patches in the deployed website.
so i'd say B for now with the above 😋

@atxr

• We currently use the main branch as develop branch.

i think it's enough for our projects 🤔
first of all, we use the "feature branch" gitflow right? maybe the "fork" gitflow 'cause it looks similar if some of us use forks?

according to me, the "feature branch" looks right for a small project as ours 👍
and when reading the first paragraph of this and this, i do not know if it would be that great to change to "gitflow"...

it looks quite cool for the orange hotfix, but apart from that i feel the only reason to switch would be to try it out and gain experience in workflows, not really to solve issues in this project 😋
which can be a legit reason to switch do not get me wrong 😉

• How to redesign our whole git tree, isn't it too late?

we could switch from now on, that wouldn't be a problem 🤔
we freeze the version at 6d7a9f6, create a new develop branch from there and start the strategy as defined in the links above 👍
we can even change the PR branch from within open PRs, e.g. request a merge in develop instead of main in #47 👌

[amtoine]

and i marked the comments as "off-topic" in #51 👍

[ctmbl]

tks a lot!

[amtoine]

😉

[ctmbl]

So here are my answers:
@atxr

Hence, if we want to use this we have two issue to address:
- We currently use the main branch as develop branch.
- How to redesign our whole git tree, isn't it too late?

This is because we use the GitHub flow and not the git flow!!
So if you want to redesign our whole git tree you're aiming to change the flow we chose, I'd prefer not to.
GitHub Flow is fine enough in my opinion, particularly in a DevOps context which ideally aims to deploy every new PR merged (I could explain my point further if you want, but a simpler argument would be: GitHub Flow is complicated enough for new comers and the project size).

[amtoine]

GitHub Flow is fine enough in my opinion, particularly in a DevOps context which ideally aims to deploy every new PR merged (I could explain my point further if you want, but a simplest argument would be: GitHub Flow is complicated enough for new comers and the project size).

agree 👍

[atxr]

This is because we use the GitHub flow and not the git flow!!

I never spotted the difference between these flows! Thanks for this!

[ctmbl]

@amtoine

first of all, we use the "feature branch" gitflow right? maybe the "fork" gitflow 'cause it looks similar if some of us use forks?

Sort of, yes but I learned of it in the name of GitHub Flow (or is it not the same?) so I'll stick to this name personally (see both links I posted above)

and when reading the first paragraph of this and this, i do not know if it would be that great to change to "gitflow"...

as I said above, I totally agree 👍

@amtoine @atxr

TL;DR (summary):
Because we started off with GitHub Flow, and because of the 2 reasons I gave to atxr I would like to keep going with it, thus I propose to truly and fully follow the DevOps philosophy and trust our code review and not-yet-but-soon-existing test pipeline and to stick with the A proposition specifying the changes in a complete change log.
The idea is: yes these changes weren't supposed to be released before v0.2.0 but that doesn't mean they can't be released now with a v0.1.1 (or other to-be-determined version).
Maybe in the future we'll face major changes that can't be released with a patch but I believe that's not the case here (at most we should jump to v0.2.0 early because of the production mode added), then we'll maybe face this future-potential challenge with a different answer, but for now A is sufficient in my believe 👍
However if both of you don't agree I'm opened to B but not to completely changing our workflow 👍

[atxr]

That looks great and easier than B.
I would add that because it's a website, the client doesn't have to download the app again after each release, it' s up to us to deploy when something is released.

Let me just highlight this:
Imagine I start developing the user page feature, which will probably be many lines of code. Thanks to the previous discussions on this repo, I will try to do many little PRs instead of one big PR.
Then, in this case, we shouldn't merge these little PRs on main as long as the whole feature isn't finished.
We should in this case open a feature branch and merge on this branch the little PRs. Once the whole feature is over, we can then merge the feature branch on main. Thanks to this, if we have a security issue during the feature development, we can still fix and deploy quickly without being stuck by the unfinished feature.
This might sound obvious regarding the DevOPS rule that we shouldn't push unfinished code/feature on main, but I wanted to highlight this 😃

[amtoine]

sounds great, the feature branch to isolate and split a big feature into many little PRS 👌

[ctmbl]

Actually, I understand your case but I see it otherwise:

• it is, sort of, using a git flow, but with feature instead of develop and PR to merge develop instead of a proper merge (or am I not seeing big the difference?)
• in the end it will require a big PR to merge feature once finished, and PR management (into which branch is this merging) can be quite tedious
• I'd personally prefer to use one of these methods:
  • develop "invisible" features first (all the backend to support the new feature) --> this can be deployed without issue; and once the whole backend is here develop the frontend allowing finally the user to use the new feature
  • use "feature switches" to enable and disable features that are not production-ready! these switches can: be a var in the .env, be hardcoded in the code, requested to another service that is the only goal. Actually this is quite common in the industry! and I find the method really elegant

[amtoine]

• it is, sort of, using a git flow, but with feature instead of develop and PR to merge develop instead of a proper merge (or am I not seeing big the difference?)

imo it is kinda the same, you right

• in the end it will require a big PR to merge feature once finished, and PR management (into which branch is this merging) can be quite tedious

the "big PR" you talk about does not appear usefull 🤔
if all the "little PRs" have been merged in the feature branch, they have been approved and thus the overall branch containing all these commits is being approved implicitely
there might be a little extra review in case the main branch and the "big branch" have diverged but not nearly as much as all the little reviews combined 👍

it's not easy to think about all of this without a drawing 😮

• I'd personally prefer to use one of these methods:

  • develop "invisible" features first (all the backend to support the new feature) --> this can be deployed without issue; and once the whole backend is here develop the frontend allowing finally the user to use the new feature
  • use "feature switches" to enable and disable features that are not production-ready! these switches can: be a var in the .env, be hardcoded in the code, requested to another service that is the only goal. Actually this is quite common in the industry! and I find the method really elegant

but in the end, these look great too, especially the "switches" 😏

[ctmbl]

@amtoine
Yes I really like the switches too!