Was there a re-release?

[mightyiam]

The hash for the v5.0.0 tag seems to no longer match, breaking this package.

[mightyiam]

Hrm... I tried building it a second time and it built successfully. Not sure what happened there.

[hollesse]

Hi @mightyiam yes we had some problem while releasing and therefore deleted releases and recreated them. So does it work or do we need to change something that the package works again?

[mightyiam]

It's a problem theoretically at this point. Practically, most users of mob via nixpkgs would enjoy the publicly available cache. But if for whatever reason they would not (and there are valid reasons) it will most likely fail to build locally. Which is probably what happened in my case.

To solve this immediately, make a another release. The nixpkgs package would have to be bumped to that new release and that's that.

Going forward I would recommend treating tags as immutable. I would also recommend automated releases. If you're interested in some examples, I have set this up in a quite a few public repositories that I can share.

[gregorriegler]

Hi @mightyiam, yes I did delete and create the release several times because of troubles with our release automation which was just not working anymore due to changes outside of our code.

So our release is automated. But there is room for improvement. I agree, tags should be immutable, and IMO to fix a publish step (which can break at anytime), I should not have to create another tag / build artifact / hashcode. I would like to separate "build and create artifact & hashcode" from "publish". The one may trigger the other, but a failed publish should not invalidate a succeeded build. And the pipeline should make sure that the "build and create artifact & hashcode" step always works. So when I have a green pipeline, I need to be confident to release. Maybe the publish step wont work, but "build and create artifact & hashcode" will always work. And when a publish doesn't work, which may always happen, I should not have to change the built artifact / tag.

[mightyiam]

I think for all my automated releases I use semantic-release. It has a plugin system. Each plugin has a validation hook, in which it tries its best to make sure that when it's its turn to do some effect, it will be able to do so.

For custom actions I use the arbitrary command plugin, https://github.com/semantic-release/exec.

[gregorriegler]

Refining my thoughts: I think that we need two actions. One that does the

Release

It includes

• running tests
• building artifacts
• generating checksums
• create tag
• create github release
• put notes
• upload artifacts to release

Most of those steps can be fully automated or are already so. All of these steps should be zero risk as they are done frequently in the CI Pipeline.

And another one that does

Publish

This includes everything that is necessary to distribute our package to AUR, homebrew, whatever...

Publish is triggered by a newly created, already completed successful release that includes all necessary artifacts already uploaded to it. So the release never changes. It is immutable, such as its underlying tag is.

The publish steps maybe rerun in case of failure. They maybe changed in case of failure. Fixing publish steps does not change the release tag nor the release nor the artifacts nor the checksums.

Thoughts @hollesse , @simonharrer ?

[simonharrer]

I think we should simply release more often, striving for monthly releases perhaps, or even more often. That’s how we make sure we detect issues more quickly and we improve the release process if we realize that the trade off between manual work and the effort to automate is no longer acceptable. And I am not sure any major change to this release process is worth the effort. I probably would not invest too much there, accept some hiccups, and invest more in a better tool. But that being said, your approach makes sense. So feel free to invest the time and energy, you probably will make it better with your improvements. :-)

[simonharrer]

And the quickfix could always be to simply release a patch fix release when something went wrong and we want to fix it. Just fix forward.

[mightyiam]

+1 for releasing conditionally on each push to the default branch.

[gregorriegler]

+1 releasing every little change immediately

[mightyiam]

I'd be happy to help with semantic-release if you happen to use that.

[simonharrer]

I habe the feeling that we do not have the complexity that would require a dedicated solution like semantic-release

I would rather go with a simple solution that keeps the project simple. Otherwise, one needs to understand semantic release to maintain the release process. I always shy away from that as us maintainers have limited time and this is not a fulltime project but rather one where we spend at most a couple of hours per month. And I temd to forget how complex libraries and tools work when I do not use them daily…

[mightyiam]

So you'd spend more time setting up something custom to avoid the complexity of an off the shelf solution that you've been offered help with and you think that the result would be somehow cheaper to maintain.

[simonharrer]

I am not sure where this conversation here is going. I really appreciate the offer to help out if we want to use semantic-release. And at the same time I would rather not become dependent on a library for the release process that I barely know. As maintainer, I must always be able to fix any issue in the release process in case of failure quickly. That is my responsibility. If we would decide to use this library, I need to learn it so that I can fix any issues. I rather would help make the tool better than invest too much in a release process. To me the release process is good enough. Why should I invest there? Why not keep it a very simple step by step process I can read in the github workflow file?

[mightyiam]

The first major issue one may face when attempting to implement such a simple step by step process is that failure at some steps along it may result in a state that can be described as an incomplete release. Which seems to be the state that later progressed into the re-creation of a tag that was reported in this issue.

In semantic release, as I wrote:

Each plugin has a validation hook, in which it tries its best to make sure that when it's its turn to do some effect, it will be able to do so.

These are critical. So either an off-the-shelf tool such as semantic-release or built it yourself with such constraints applied.

To me the release process is good enough. Why should I invest there?

Well... I don't know what went wrong exactly.

Regarding semantic-release maintenance cost: from my experience, it is low. It is nearly zero, if used via the GitHub action, because then there is no checked in dependency tree.

[gregorriegler]

how would the semantic-release plugin have prevented our release issues?

This is the first issue that happened: https://github.com/remotemobprogramming/mob/actions/runs/9726879497

[mightyiam]

No, I don't think this would have been prevented by semantic-release.

Is it possible to build for all targets on the same host? That would simplify the workflow.