snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
11.1k stars 3.18k forks source link

Release branches #10896

Open joelpittet opened 2 years ago

joelpittet commented 2 years ago

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 and master.

Describe the solution you'd like A clear and concise description of what you want to happen.

For example having branches like 5.x and 6.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/drush

Additional 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.

welcome[bot] commented 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.

snipe commented 2 years ago

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.

joelpittet commented 2 years ago

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

joelpittet commented 2 years ago

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

GitHub
deployer-recipes/base.php at feature/7.x-compatibility ยท ubc-cpsc/deployer-recipes
UBC CS Deployer recipes. Contribute to ubc-cpsc/deployer-recipes development by creating an account on GitHub.
snipe commented 2 years ago

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.

joelpittet commented 2 years ago

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.

snipe commented 2 years ago

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.

joelpittet commented 2 years ago

Totally understand, let's let this idea marinate a bit ๐Ÿ˜€