Nightly releases

[orhun]

Problem

There might be some time gaps between new releases so the users cannot test/use the latest functionality without using ratatui as a git dependency in Cargo.toml which makes the crate unpublishable on crates.io. (crates.io doesn't accept git dependencies)

See what atuin did recently as a workaround: atuinsh/atuin@a515b06

Solution

Create automated nightly releases every week or so. ratatui can be used as e.g. version = "nightly-2023-04-21" afterwards.

Alternatives

Just plan things out and release more frequently.

Additional context

None.

---

We need comments/thoughts on this.

[mindoodoo]

This is a great idea, having automated nightly releases will help us a lot.

How often though ?

I think depending on activity something like every two weeks might be good, maybe every week might be a bit excessive, let's hear other peoples thoughts on this though !

Looking forward to this 🚀

[sophacles]

Why not every day that there's been a merge that changes the code or docs?

Should the version be nightly-$date or something like $next_version-alpha.$N (so if we start today, 0.21.0-alpha.1 from my reading of https://doc.rust-lang.org/cargo/reference/resolver.html#pre-releases I'm no sure how nightly-date would be handled or ordered relative to other things.

I know when I'm working on a project, and I know a feature is merged but not released, I'd like to have updates by setting version=....-alpha as I'm developing my stuff.

[sayanarijit]

Inviting @extrawurst to the conversation.

[extrawurst]

I like the idea of daily releases iff there was a change.

[mindoodoo]

Someone also mentioned on discord that separating these releases to another repo might be interesting in order to not inundate people with release notifications from the main repo.

[extrawurst]

Someone also mentioned on discord that separating these releases to another repo might be interesting in order to not inundate people with release notifications from the main repo.

yeah having nightly or even weekly releases/tags might become noisy.

[joshka]

+1 to building nightly (good for picking up all dependencies and being aware of new breaking changes etc).
-1 to releasing nightly (I prefer intentional with releases so that you're aware what goes into each release - 0.21.0-alpha.2 should have an obvious reason to exist compared to 0.21.0-alpha.1)
+1 to pre-release releases that can be cut with new features that are being tested at any time
+1 to releasing more often (perhaps as often as any new feature merge = a point release)

One thing I've found that works quite nicely for setting up rolling nightly builds plus a matrix of builds over ubuntu/mac/windows is https://github.com/jonhoo/rust-ci-conf/
There's a supporting youtube that talks through adding this in a fashion where updates from source are possible (grafting an unrelated git branch so that the history is preserved is useful).
See https://www.youtube.com/watch?v=xUH-4y92jPg&t=491s (the rest of the video is probably worth looking at too, but this is where the setup happens). One of the good / hard things that this does is that it helps work out actual minimum versions and MSRV to avoid build failures in downstream. That said, it suffers when upstream incorrectly specify their required versions).

Also nice is https://opensource.axo.dev/cargo-dist/ and https://github.com/crate-ci/cargo-release

[mindoodoo]

Reviving this issue following the 18/07/2023 general meeting → #316

• General consensus is that we should set up nightly releases
  - Frequency → once per week
  - With option to trigger manually in case by case basis

cc: @orhun @joshka

[orhun]

I will be working on a GitHub Actions workflow file soon!

[mindoodoo]

Awesome thanks !

[orhun]

Just realized crates.io does not recognize nightly-<date> versioning schema as pre-release so we need to go with either e.g. 0.22.0-beta.0 or 0.22.0-alpha.0. Any thoughts?

[joshka]

Strong opinion: -alpha.0 for nightlies.

Use -alpha to indicate that the next release will happen whenever there is more commits merged on that day. There's no contract that these won't introduce bugs, or unwanted changes in behavior. Effectively no hard commitment to quality.

Use -beta to indicate that the release on the path to stabilization, and that the release was intentional rather than just something that happened. You might use this to test that a large change or new feature works in some app before releasing that version of ratatui to the wild.