search

roboll / helmfile

Deploy Kubernetes Helm Charts
MIT License
4.04k stars 566 forks source link

Release Helmfile on Merge to Master #175

Closed osterman closed 6 years ago

osterman commented 6 years ago

what

why

use-case

Helmfile moves quickly! We use your binary releases in a lot of our projects.

We want to use the latest features, especially the ability to use helmfile.d as part of our release engineering process, but we don't want to fork/build helmfile, if we don't need to.

As maintainers of Open Source (200+ repos), we also faced the problem of when to release. The only scalable solution we've found is to release on every merge to master. Stability is achieved by version pinning, not by holding back code. Regressions are inevitable. But if there are no binary releases, a much smaller percentage of people will use/test the new features.

mumoshu commented 6 years ago

@osterman Hey! Thanks for the detailed feedback and the request. I generally agree with this.

In different words, the only thing I was afraid about it was the possibility to bloat up our github releases pages with a lot of "rc" releases.

After looking into one of your awesome projects' release page, it seems like you're bumping only patch ver. on every merge? When and how do you bump minor/major vers? I want to learn more 😃

osterman commented 6 years ago

@mumoshu thanks for checking that out!

(btw, Abraham Ingersoll @ gravitational showed me some of the nice helm charts you're working on for teleport)

the only thing I was afraid about it was the possibility to bloat up our github releases pages with a lot of "rc" releases

I guess we (cloudposse) forgo the concept of RCs. It's too hard to mentally constitute what is considered a release if it's based on some discretionary process. This is why I prefer to have the rules relatively black & white. For example, cut one release per unit time (e.g. day or week). In our case, it's per-merge to master.

it seems like you're bumping only patch ver. on every merge

If a change is "non-breaking" and does not change the interface, then we just consider it a patch release. If the interface changes, we change the minor release.

Might we have broken something between those 31 releases? Maybe =/, but we try not to.

When and how do you bump minor/major vers?

Yes, this is a more difficult question.

The majority of our projects are at major==0. For us, this means the interface is still subject to signficant changes. At major==1, the interface will remain stable for some time.

So, case in point with geodesic, we're at 0.9.31.

This reads like: "This is the 9th minor interface change and we've at 31 enhancements with the current interface. Additionally, since it's pre-1.0 the interface is subject to change rapidly."

In the end, our driver is to make it as easy as possible for people to use our software (including bleeding edge) without needing to know how to compile it.

osterman commented 6 years ago

Wish we could get a new release pretty please =) so we can deploy our stuff with helmfile.d

https://github.com/cloudposse/geodesic/issues/157

osterman commented 6 years ago

Another consideration is to use the "pre-release" feature if you guys want to call out this may not be fully baked yet. Really, just want the binaries so we can continue distributing it without compiling it.

image

mumoshu commented 6 years ago

Thanks for all the guidances! --I'm working on this by firstly introducing CircleCI into this project.-- --I have a working set of automated tests on my fork but it is not yet enabled here.-- Oops, I was mistakenly talking about another project. I'm working on this anyway.

osterman commented 6 years ago

Looks like you're doing this now! Thanks guys so much for releasing regularly.

mumoshu commented 6 years ago

Yeah, I do this manually 😉