Open snaildos opened 4 years ago
More information on why this would be helpful: 1) People don't have to build. 2) People can just download the file.
Disadvantages: 1) No installer. Maybe there could be a way to build a installer during the building process. I'll look into this. 3) Even though we have azure there isn't a way (that I know of, maybe i'm just dumb.) to download the executable?
we had discussed this but trying to figure out a few ways to do this.
We'd host the infra :)
we had discussed this but trying to figure out a few ways to do this.
We'd host the infra :)
Alright, wan't me to close this?
Or I can help with this development.
we'll use this as the tracking item for nightly builds
Uh, Is this something I can help with?
We need to do the work here to enable this. It needs to be off our infra. I also think we should sync with our good friends on terminal to see how they do this / coordinate so we act the same.
Alright.
Bump...?
This is dependent on the versioning tweaks, as well as, better upgrade process. Right now upgrading is a pretty aggressive due to UAC
My thoughts on this:
I think different release channels would be good. So in a certain way we have them with the expermental releases.
When we do this it should be...
Also on a product like PowerToys it would be cool to have a canary release channel (with unstable releases), but I think that would cause too many issues in this repository. (So maybe use something else (or a other repository) to track canary bugs).
Something we should also think about is should be make a system that works like:
A version is first in canary then in nightly and then in stable
or
A feature is first in canary then in nightly and then in stable
@crutkas I would love to create the spec for this. Is this OK?
Not something we are currently planning on supporting in the near future. Possibly after we hit stability but my gut says people would prefer the team to focus on bugs / features / new utilities.
Since we're fully open source and the project should always be F5 ready, i don't see this as a mission critical item.
(I came here because I almost filed a dup of #19670 which is marked a dup of this.)
It has been several occurences in a row that one hotfix patch comes shortly after a v0.Y.0 release that quote
fix issues in v0.[Y].0 we deemed important for stability based on incoming rates.
(We are approaching 77 v0.Ys now. At this rate of stability, v1.0 when?)
If we have separate preview and stable channels, early adopters and bug hunters can catches critical issues before they reach the mainstream, whose users no longer have to download v0.Y twice because their v0.Y.0 keep falling apart (or is in risk of).
Why not utilize GitHub’s distinction between releases and pre-relases to publish betas and/or release candidates?
Not really a feature request, more like a helpful suggestion I could do. I have a server and maybe if you guys think I should setup a release system? Such as: Master, Stable, Nightly builds? Up to you! Please react with reactions if you think this is a good idea, -3 reactions and i'll close this. (I'm not sure how I would do this but, it's up to the person running this!).
More information on how I would run this: 1) It would run jenkins. 2) Links could be in readme.md 3) I'll give the operator of this repository full access of the Jenkins website.
Thank's all!