Well, it's been a few days and I'll assume the silence from anybody
else gives consent. <g>
On Wed, Jun 23, 2021 at 8:26 AM Frédéric Fouret
<fouretfrederic@xxxxxxxxx> wrote:
I'm ok with this.
Le mer. 23 juin 2021 à 14:23, Darryl L. Pierce <mcpierce@xxxxxxxxx> a écrit :
So I think my main issue is in wanting to have everything on a single
branch, and by "everything" i mean having a pure, linear history that
includes tags that branch pointing to each release. And I think this
is an unrealistic expectation.
So what I think we should do is this:
1. move all development to master,
2. created a branch for each release that is short lived,
3. never merge the release branch into master, but instead create
releases from that branch,
4. tag off of the branch, and
5. delete the release branch when the next release is created.
We don't have to worry about losing history for releases since tags
persist after the branch is gone. But this would make the whole
merging issue I'm dealing with right now go away since releases branch
off of master and never merge back. And the only changes that should
be made on those release branches is to bump the version in the
pom.xml and package.json files.
How does that sound?
If nobody has any objections, then I'll make that change this coming
weekend, replacing master with develop and creating the release/0.9
branch off of it.
On Mon, Jun 21, 2021 at 9:06 AM Darryl L. Pierce <mcpierce@xxxxxxxxx> wrote:
On Mon, Jun 21, 2021 at 3:43 AM Frédéric Fouret
<fouretfrederic@xxxxxxxxx> wrote:
I'm sorry if I'm not very responsive lately :)
It's all good. It's one of the perks of open source projects: freedom
to participate when we're available. :D
At work, on an old project we worked with only master et branches for
each issue.
When a PR is approved and tests accepted by the QA team,we merge in
master.
For each release we make a tag and if needed for hotfix, we can take a
branch from the tag and make the fix and deploy in production the hotfix
branch. (i think we can rebase master on to the fix branches to keep the
hot fix in master and create a new tag for this fix version)
That last part (rebasing master) is the part I have a problem with: I
don't think we should alter history on a shared branch like that. It
can lead to problems.
I do like the idea of just master as the goal branch with feature
branches merged into it.
For a hot fix, we could 1) create the fix on master, then 2) create a
branch from the previous release's tag, 3) cherry-pick the fix and 4)
tag the hotfix. But then the question for me is what do we do then? We
can push the tag, but it's not really on master. And I'm not sure we'd
want to then merge that back onto master, and rebasing master on it
could introduce merge conflicts if the fix is in a file that's been
touched a few times after the point where it's rebased.
Right now our automated release builds are triggered by a tag on
master getting pushed. What do you think about using Github Flow?
https://guides.github.com/introduction/flow/
I'm doing some playing around locally with a test repo and I think we
can get this to work. The only thing it does that I'm not fond of is
the merge commit when you do a fast-forward merge from a hotfix
branch. I hate merge commits, I prefer things be linear if possible
since it makes it impossible to do a rebase. But master should never
be rebased, so maybe that's not a big deal?
What do you think of that? It seems like what you do at work, but
without rebasing hotfixes.
--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie
--
Darryl L. Pierce <mcpierce@xxxxxxxxx>
"Le centre du monde est partout." - Blaise Pascal
"Let's try and find some point of transcendence and leap together." -
Gord Downie
