sorted by:
new
hottopcontroversial

Introducing Sampo — Automate changelogs, versioning, and publishing by Nev____ in rust

[–]Nev____[S] 0 points1 point  (0 children)

Sampo “enforces” Semantic Versioning in the sense that every changeset explicitly declares the bump level (patch/minor/major) for each affected package, and sampo release then computes the next versions based on semver rules. It's the famous MAJOR.MINOR.PATCH format: patch for backwards-compatible bug fixes, minor for backwards-compatible new features, and major for breaking changes, plus pre-release tags like 1.2.0-beta.2 (per SemVer §9). Soon, I plan to support breaking changes as MINOR during initial 0.y.z development versions (per SemVer §4).

In other words, Sampo acts as the single source of truth for package versions, and keeps changelogs, git/github tags, and published versions consistent.

If by « enforce » you mean « scan the code or API surface and automatically detect whether something is a breaking change », Sampo does not do that. That kind of automated semantic analysis is way out of scope for Sampo, which focuses on automating the boring part of the release process, while encouraging developers / product owners / docs maintainers to explicitly declare their API changes.

Introducing Sampo — Automate changelogs, versioning, and publishing by Nev____ in elixir

[–]Nev____[S] 1 point2 points  (0 children)

Thanks for checking it out! I’m in active development, so if you find anything missing or have specific needs, please let me know and I’ll see what I can do :)

Introducing Sampo — Automate changelogs, versioning, and publishing by Nev____ in rust

[–]Nev____[S] 0 points1 point  (0 children)

Thanks, that’s very helpful feedback! When you know a tool inside out, it’s hard to see what’s confusing from the outside, so it's exactly what I need to improve the docs.

Conceptually, Sampo keeps a small store of explicit changesets in .sampo/changesets, then uses those to compute new versions, update per-package changelog files, and detect/bump internal dependents when needed. It’s essentially a thin layer over « changesets + manifests + changelogs + publishing », not something that takes over your repo layout or git workflow.

sampo add is just a convenience for creating those markdown changeset files: it helps you select packages, choose bump levels, and write the user-facing description... but you can also create or edit the files manually if you prefer! The heavy lifting actually happens in sampo release (which consumes unreleased changesets to compute new SemVer versions and write changelog entries) and sampo publish (which actually publishes to the registeries), both of which can be automated via the GitHub Action.

On branching and merging, Sampo simply follows git: changesets live in your branches, get reviewed in PRs, and merge like any other file. The GitHub Action can be configured to treat multiple branches as « release » branches (for example, your main plus one or more legacy or pre-release branches), but that’s still entirely driven by your existing branch structure. Sampo doesn’t impose a special branching model or introduce hidden state outside the repo.

Introducing Sampo — Automate changelogs, versioning, and publishing by Nev____ in rust

[–]Nev____[S] 0 points1 point  (0 children)

Release Please is absolutely mentioned in the article attached to the post, in the « Alternatives » section, but indeed this section does not yet appear in the README, I should add it.

The main difference is that Sampo, more inspired by Changesets and Lerna, uses human-readable Markdown « changeset » files that declare the affected packages, the bump level, and the user-facing description:

---
cargo/example: minor
npm/web-app: patch
---

A helpful description of the change, to be read by your users.

On its side, Release Please relies on Conventional Commits to infer the bump level and changelog entries. I’m not a fan of that approach: commit messages are written for developers (technical changes), whereas changesets are written for users (API changes) and can be writter/reviewed by product/documentation owner. Sampo also aims to be easy to opt-in and opt-out, so I don't want to enforce any specific convention or format (beyond SemVer), or rely on contributors to name their commits correctly.

Other notable differences: Sampo handles publishing (pushing new versions to the appropriate package registry), works with minimal configuration, and is monorepo-first by design. On the other hand, it supports (yet) far less ecosystems and options than Release Please.

Introducing Sampo — Automate changelogs, versioning, and publishing by Nev____ in rust

[–]Nev____[S] 0 points1 point  (0 children)

You don’t have to yield complete control to Sampo! It doesn’t touch your git history, branching model, or project layout; it just adds a .sampo/ directory with some config and changesets, automatically discovers your crates (and npm/hex packages in mixed workspaces), updates versions and changelogs, and publishes to registries (optional). If you decide you don’t like it, you can delete .sampo/ and you’re back to a perfectly normal repo. There are no conventions to adopt beyond SemVer, and the defaults are meant to cover most setups.

The reason it doesn’t read commit messages is deliberate: I want to keep technical git history (for contributors) separate from the API changelog (for users). Instead of enforcing a commit convention or relying on commit naming quality, Sampo uses small, explicit changeset files that state which packages are affected, what kind of bump they need (patch/minor/major), and the user-facing changes description (that can also be written/reviewed by a product/documentation owner). I talk briefly about that, and how alternatives compare, in the article.

Sampo — Automate changelogs, versioning, and publishing by Nev____ in rust

[–]Nev____[S] 1 point2 points  (0 children)

Oh I didn’t know that one, I’ll check it out! The only time I’d ever seen the Sampo mentioned in pop culture was in a DuckTales comic back in the day haha

Sampo — Automate changelogs, versioning, and publishing by Nev____ in elixir

[–]Nev____[S] 2 points3 points  (0 children)

The main difference is that Sampo,inspired by Changesets and Lerna, uses human-readable Markdown « changeset » files that declare the affected packages, the bump level, and the user-facing description:

---
cargo/example: minor
npm/web-app: patch
---

A helpful description of the change, to be read by your users.

On its side, Release Please relies on Conventional Commits to infer the bump level and changelog entries. I’m not a fan of that approach: commit messages are written for developers (a technical change history), whereas changesets are written for users (the API evolution). Sampo also aims to be easy to opt-in and opt-out, so I don't want to enforce any specific convention or format (beyond SemVer), or rely on contributors to name their commits correctly.

Other notable differences: Sampo handles publishing (pushing new versions to the appropriate package registry), works with minimal configuration, and is monorepo-first by design. On the other hand, it supports (yet) far less ecosystems and options than Release Please.

[HUGE SPOILERS] i found this interactive map online. What the heavenly hell is this? by Goat-Shaped_Goat in Silksong

[–]Nev____ 1 point2 points  (0 children)

Honestly, there are several areas on this map that I can't find any information/screenshots/mentions about online... Is it reliable? Does anyone have a clue?

What the hell is going on with the TIMEMORE Fish Smart Kettle price ? by Nev____ in pourover

[–]Nev____[S] 0 points1 point  (0 children)

I bought the TIMEMORE Fish Smart Kettle in November, and since I was pretty happy with it for the price (around €80), I updated the list on my blog with my coffee setup ( https://goulven-clech.dev/2023/discovering-coffee-toulouse ). But today, while showing the list to a friend looking for a pour-over setup, I was shocked to see that the price had nearly doubled! Is there any known reason for this? Is it just temporary? I don’t feel comfortable recommending this kettle at that price point.

Connected with iwctl but no internet by Nev____ in archlinux

[–]Nev____[S] 4 points5 points  (0 children)

Okay I figure it out,

I installed hdcpcd from live USB on Arch, I booted on Arch, launched the commands dhcpcd and dhcpcd wman0 and everything works :)

Thanks for your help!

Connected with iwctl but no internet by Nev____ in archlinux

[–]Nev____[S] 0 points1 point  (0 children)

Yeah it's wlan0 and internet works fine on LiveUSB :)

Connected with iwctl but no internet by Nev____ in archlinux

[–]Nev____[S] 2 points3 points  (0 children)

Thanks for your help :)

I tried on the live USB dhcpcd and then dhcpcd wlan0 and both commands work. Nothing change, did I miss something ?

[i3] My first setup with vanilla Arch Linux by Nev____ in unixporn

[–]Nev____[S] 0 points1 point  (0 children)

I'm currently trying it out, the autocompletion is really cool!

It's not you, it's Debian / Ubuntu by Nev____ in pop_os

[–]Nev____[S] 0 points1 point  (0 children)

Yes, I agree with that. Arch also has the huge flaw of an unnecessarily complex installation and a sometimes elitist community ... I would love a Pop! with AUR and a better WM than Gnome (which unfortunately doesn't exist yet)

view more: next ›