Make 'next' a fast-forward version of 'master'

[Stealthii]

I appreciate the use of squash merge commits when merging PRs into next, it helps keep history tidy and highlights complete features. However, using squashes for merges from next to master erases the individual history of those PRs implementing new features, and the names of those who contributed (with as an example v1.5). There's also the problem of fixes and changes being implemented in master but not being merged back into next.

Would you consider maintaining master as the stable release, but rebase the current next on top of it and keeping next as a PR target and straight fast-forward merge into master on release day? This way individual PRs keep their status as an individual commit, without bloating history.

[Stealthii]

rebase the current next on top of it

Actually having gone through next, all of the commits that aren't in master are already implemented in the v1.5 release and covered by the master branch entirely. It might be simpler to just reset next to point to the same HEAD as master right now before merging any open PRs. This should clean up all of the dead references.

Changed the base back to 'master' for #70 & #72 until 'next' is fixed for now.

[janoamaral]

next branch is rebased, I believe that we are ready to implement this. If you like, please change the PRs to point to next

[Stealthii]

@janoamaral the two branches are still diverged, containing different commits representing the same change:

❯ git lg upstream/master | head -n1
* 0801746 - (upstream/master) fix: web based git provider shows even if there is no extra data (7 days ago) <Alejandro Amaral>
❯ git lg upstream/next | head -n1
* a7e09a0 - (upstream/next) fix: web based git provider shows even if there is no extra data (5 days ago) <Alejandro Amaral>

This prevents branches from master being cleanly applied to next using a rebase workflow. I'd recommend just doing a clean reset of next to point to the same HEAD as master as they're both change-wise the same branch right now.

git checkout next
git reset --hard origin/master
git push -f

[janoamaral]

Done

[janoamaral]

Yes, that’s correct. The strategy allows anyone to make PRs. These are then squashed while maintaining the conventional commits specification, and as you pointed out, rebased to master to ensure users receive a stable release. I’ve made several hotfixes, so I believe implementing this strategy would be a better approach.