Releases

[rbtr]

@aojea: Releases should have a purpose, I want to understand the motivation first, what is missing? What are we trying to solve? Let's open the discussion...

It's been a few weeks since the last release.
There's a number of changes that are important for Azure since then: #176, #156; and others/nice-to-haves: #191, #193. (Not an exhaustive list.)

Schedule

I would like an established release policy, so that as a contributor I know when to expect my changes to be officially available. As a maintainer, I would not want unnecessary releases with no or no-effective diff, so a fixed release schedule may not be right. But maybe we do something like "when a feature/fix is merged it starts a 1-week timer to the next release".

Releasers/Release approvals

Is the release process still started by pushing a tag? "Push a release tag (e.g. v1.1.0)". Who are releasers, only maintainers? Should there be any additional consensus/review required before a tag gets created?
Allowing anyone with repo-write to manually create a tag has caused problems for me on other projects before - a misplaced tag or a typo becomes annoyingly permanent in the go mod proxy, even if git tags are technically mutable.

cc @tamilmani1989

[aojea]

We can do a release anytime that is needed, adding a schedule if there is nothing to release is also confusing, if anyone needs some patch we evaluate if we release a new minor or a new patch, we have now a slack channel and github issues to have these conversations ... based on these interactions we will keep evaluating what are the best way of organizing ourselves.

Should there be any additional consensus/review required before a tag gets created?
Allowing anyone with repo-write to manually create a tag has caused problems for me on other projects before - a misplaced tag or a typo becomes annoyingly permanent in the go mod proxy, even if git tags are technically mutable.

I do not know which projects you worked with but that is not my experience, the release is something serious, there can be mistakes, but I will keep the circle of people with release powers small and with a clear commitment with the project

[rbtr]

Saying "anytime it is needed" probably means everyone thinks their change needs to be released immediately and tries to find you and ask for a release ad-hoc. Even if the process is "ask maintainers to do a release", when that can happen and what qualifies as significant enough to trigger a release (major/minor/patch) is a mystery.
A dependabot upgrade could usually sit until the next feature release, unless it's a CVE or totally broken and needs a hotfix; maybe individual changes aren't worth their own release, but we build up a backlog of improvements like the various Azure PRs that have gone in over the past month.
Even saying "at least monthly releases to pick up features, dependency updates, CVE bumps, go versions" would set expectations for those and other accumulated changes to be available.

[aojea]

Even if the process is "ask maintainers to do a release", when that can happen and what qualifies as significant enough to trigger a release (major/minor/patch) is a mystery.

It is not a mystery if these conversations happen transparently in an open GitHub issue or in our public channel.

A dependabot upgrade could usually sit until the next feature release, unless it's a CVE or totally broken and needs a hotfix; maybe individual changes aren't worth their own release, but we build up a backlog of improvements like the various Azure PRs that have gone in over the past month.

Do you need a release cut for those PRs right now? Just ask for it. This is OSS; it works by people just talking with people.

Even saying "at least monthly releases to pick up features, dependency updates, CVE bumps, go versions" would set expectations for those and other accumulated changes to be available.

Who are "those"? We cannot guess what the community wants if they are not communicating with us.

This is a small project with a very clear scope and a high bar on quality. As you can see, all code must be backwards compatible and not break upgrades. We are growing a community and we will keep revisiting things based on facts and open discussions, so if you have ideas, feel free to speak up.

[MikeZappa87]

Let's see about getting a release scheduled? Perhaps we can iron out some of the finer details as well as DRAnet is now a managed offering across a couple clouds so a level of due diligence is required however I would expect those companies offering the managed offerings to also conduct their own DD. That being said, what can we do to this over the finish line?

[aojea]

@gauravkghildiyal just released

https://github.com/kubernetes-sigs/dranet/releases/tag/v1.3.0

Feel free to suggest improvements to the process

Thanks