Open joelpittet opened 2 years ago
๐ Thanks for opening your first issue here! If you're reporting a ๐ bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
Unfortunately, there are bunch of different workflows that people use to automate updates (including us), so I feel like changing that would break a lot of people's setups. We'll give it some thought tho.
I guess the hybrid model could work, where you leave the master branch to be the (latest stable releasable code) as you have it, and ditch the develop
branch in favour of 5.x
and 6.x
respective develop branches, or to transition yourselves leave the develop
branch too as a mirror of 6.x
and master
as mirror of 5.x
Thanks for considering it, I know the woes of breaking automated tools, I'm trying to change all my master
to main
and ended up writing this to check which one exists in bash: https://github.com/ubc-cpsc/deployer-recipes/blob/feature/7.x-compatibility/recipes/base.php#L125
GitHubUBC CS Deployer recipes. Contribute to ubc-cpsc/deployer-recipes development by creating an account on GitHub.
IIRC, changing master to main (which is something we also want to do) is easier just because we can let people know that's the primary branch now. Using release branches would mean folks would have to do an additional check for a release branch without knowing its name, etc - which makes it a little clumsier. For example, we have a lot of hosting companies that have a one-click installer (as I'm sure Drupal does). If we tell them to switch to main
, that's a change in their tooling once.
The versioned branches seems nice because development can proceed in parallel. The tricky thing might be trying to communicate which ones are "supported" and actively taking PRs towards.
There could be other interesting ideas (๐ฐ and eat it too) like main
& develop
= stable main-next
/main-tng
& develop-next
/develop-tng
but I think one of the pieces I'd like to advocate for is moving away from git-flow 2 branches and cut releases off main
and consider ditching develop
... let develop
be the fork of main
in someone else's repo.
We can't really do that right now, since this repo is on my personal Github account. I cannot go fork myself (no matter how much people might wish it ๐.) We DO plan on moving this repo over to the @grokability organization account soon, but we have a LOT of balls in the air (and a lot of changes in motion) with v6 coming and our own hosting platform's automation.
Totally understand, let's let this idea marinate a bit ๐
Snipe-IT Version
develop
Operating System
ubuntu
Web Server
apache
PHP Version
7.4
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
A suggestion (sorry if you've thought of this already and dismissed it due to the workload/shift i might take). I find it helpful when contributing to projects with major version release branches instead of
develop
andmaster
.Describe the solution you'd like A clear and concise description of what you want to happen.
For example having branches like
5.x
and6.x
and you can make releases off of the respective branches.Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
I've seen hybrid approaches where a
master
branch is still used, but I think it might not be needed. This project used to use it but I think they stopped using it now: https://github.com/drush-ops/drushAdditional context Add any other context or screenshots about the feature request here.
I'm a Drupal core and contrib maintainer and that's the direction we've headed and it seems to solve some of the issues I was reading in the release notes for 6.x RC where diverging dev & master branches.