Stable and Bleeding Edge feature for Scoop

[chawyehsu]

As more and more people found Scoop, Scoop is becoming more unstable than ever. Much more patches, enhancements, and new features request are placed on the agenda. But the problem is that Scoop doesn't have a stable version ever. Every commit, either well-done patches or buggy commits, will deliver to users very soon, it's a rolling-update software. I've talked about this problem and the concept of making Scoop stable in my blog post (Sorry for writing with Chinese, please use Google Translate if you have interests).

Scoop needs to be usable and stable to its users, stop deliver untested updates to every user. However, we also have to handle those notable contributions/requests from the community. They need some (the aggressive) users to help to test, but they don't have those users to help, because they couldn't be merged into the master branch, and nobody would like to test it unless the author. Then it is hung up because of a lack of tests. I think it's an endless loop.

Therefore, I suggest the development flow needs to be improved. In my blog post, I pointed out a master branch & version release model, which was inspired by Homebrew. In this flow, all users download and use the latest version (the latest release tag) of Scoop by default, the master branch accepts all notable new features from the community and used by the aggressive/developers. Then waiting for those changes become relatively stable, and release the next stable version after a period of time.

But I found this flow is hard to make work, in the current state of Scoop. Scoop has no version number, and the core bucket is located in Scoop's repository. This makes master branch & version release model hard to reach. Core developers have to make many changes to implement this flow.

So I'm considering another flow, Stable & Bleeding Edge model. In this flow, we don't release numeric stable versions, since Scoop doesn't have the concept of a version number. We still deliver master branch to all normal users but block all pull-requests from merging into the master branch, except for the manifest updates. Then, create a develop(or bleeding) branch to accept future patches, enhancements, and new feature requests. And aggressive users/developers can change their subscribed channel to this unstable branch by using scoop config SCOOP_BRANCH <develop/bleeding>, to use future features. (NOTE: currently Scoop cannot handle updates of changing branch very well.) After those changes become relatively stable, merge them into the master branch, deliver them to all users after a period of time.

Compared to the first flow, the second only needs collaborators to provide a fixed develop branch. With a small change, the project development will become more lively.

Last but not least, although I think we should improve the development flow firstly, I also suggest that the core bucket should be split from Scoop's repository, move it to a separate repository like scoopinstaller/scoop-core.

@r15ch13 @rasa @lukesampson @brandon93s

[r15ch13]

Fully agree with you. 👍
Separating the main bucket from Scoop's program code has to be the first step!
Also, we should consider a more secure installation process. (See: #2583)

[chawyehsu]

@r15ch13
For that issue, actually, I have refactored the installer, which now is fully independent, doesn't rely on external downloaded core.ps1 while installation. But as I said above, we can't deliver untested changes to all users, that's why I want a develop branch.

[chawyehsu]

So does anyone else have any idea about this? Though I know it's hard to say...

[Garfield550]

I agree with you, this is a nice idea.

OT: Cloudflare reports that your blog has a HTTP 526 error, Ray ID: 495545537c5ca5fc, can you fix your SSL certificate issue?

[chawyehsu]

@Garfield550 Thanks, I'll fix it soon.

[Ash258]

Could be closed.

I would move discussion into #3362 so we can develop proper release process.