Introducing umbrelOS 0.5.4 โœจ

A completely revamped App Store to help you discover all the self-hosted apps for your home server.

Brand new Migration Assistant to seamlessly transfer all your apps & data from your Raspberry Pi-based Umbrel to your new Umbrel Home.

And so much more. ๐Ÿš€

https://youtu.be/w1WYFAc3218

Reply to this note

Please Login to reply.

Discussion

nostr:npub1aghreq2dpz3h3799hrawev5gf5zc2kt4ch9ykhp9utt0jd3gdu2qtlmhct Please consider building a migration assistant for users who want to spec their own hardware and upgrade from a Raspberry Pi to something more powerful.

x2

This ^

Seconded!

Wen nostr:npub1r29mgme6rnyj5sljdnerfty9ewwnj2nje76d0qqyhvt0wkhncxvsyc23pd? This migration tool would be great upgrading from Arm based installations to x86 since most of us are trying to graduate from the underpowered Pis. ๐Ÿ™‚

nostr:nevent1qqsy5lusjjmlkjwye8lv7f49l5pxwmxvmtpwwtg7eswlc725wgy2megpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzp63w8jq56z9r0ru2tw86ajegsng9s4vht3w2fdwztckklymzsmc5qvzqqqqqqyzugtd5

Ya'll need to study https://semver.org/; never release new features in a patch release. Should have cut 0.6.0, instead.

Hahaha great comment ๐Ÿ”ฅ

It's only from writing libraries in a professional setting for a long time:

1. If you ship new functionality in patch releases, other teams learn not to trust you after outages and other ugly surprises.

2. If you stay in 0.y.z for too long, never committing to an API, other teams will get wore down by backwards breaking changes and stkp relying on your team.

Patch releases are for patches.

Minor releases are for new functionality.

Major releases are for API commitments.

Itโ€™s actually valid semver during 0.x.x releases. https://semver.org/#spec-item-4

Technically according to spec you can do anything during 0.x.x releases but itโ€™s common convention to push the meanings across one place so:

- 0.5.3 > 0.6.0 = major bump

- 0.5.3 > 0.5.4 = minor bump

- No way to define a patch bump

This is the convention weโ€™ve been following since initial launch of 0.1.0.

That's not how pre 1.0.0 releases work.

Both "major" and minor ride the y in x.y.z and patch releases are always reserved for bug fixes of existing functionaliy.

"Patch version Z (x.y.Z | x > 0) MUST be incremented if only backward compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior."

"How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release."

By launching new functionality inside of patch releases, you give developers no way to fix their version constraints to a given set of functionality.

https://semver.org/