Suggestion - no new functionality and release 1.0

@mrm - We love your work! And it’s so great to be using a self-hosted service.
Since we care lots about the excellent software you’ve written which we receive much benefit from, I’d like to humbly make two suggestions:

  • No new functionality in any 1.0 betas from now on.
  • Prioritise releasing a stable 1.0.

It’s awesome to have new functionality in the betas. Makes it pretty exciting to get the betas and try out a new setting or improvement. However every change introduced adds the risk of new bugs.

I think the priority should be to ship a 1.0 release, and then use 1.1, 1.2, and so on (or whatever version numbering you’re using) for new functionality.

  • Gets out of the never-ending cycle of fix-bug → introduce nifty feature → now fix new bugs.
  • New users will feel more confident using a non-beta 1.0 release (and especially a 1.1 or higher version imho).

We also care about your mental well-being and would like to make sure this project remains a joy for you :slight_smile:

Feel free to ignore / trash / trash-talk this suggestion. Much thanks for the hard work.


Wholeheartedly agree :+1:

I really appreciate your comment, thanks for taking the time to write!

Just to add a bit more color, I’ve really been trying to limit myself to focusing on addressing reported bugs. If you check the release notes, you’ll see almost no :sparkles: (new features)… just :bug: and :package: changes:

I’m really hoping that beta.13 is a v1.0 release candidate.

1 Like

I think way too much importance is put on version numbers, and the symbolic “1.0” release. One of my favorite project (home assistant) moved to a date-based versioning “2021.07.3” before ever reaching “1.0” (I think they were at version 0.107 before that, which was getting a bit silly.)

But if releasing “1.0” is what is going to take to get moving on the next set of major new features (editing tags come to mind), then by all means, please release “1.0” tomorrow because if you’re waiting to be bug free, that will never happen. It is more than Good Enough™ currently to move on.

I really like calendar-based versioning as well, like Ubuntu’s YYYY-0M-micro format.

The big value-add (at least to me) for semver is how it makes breaking changes be obvious to consumers: but I try to make versions always automatically upgrade to the next build, so breaking changes shouldn’t be a thing (unless there are bugs in the upgrade, which I’ll try to fix).

The only glitch I see is that I still want to do -alpha (and possibly -beta) release-candidate builds to make sure “stable” builds are actually stable. If I mark the version as 2021.07, it might be a bit confusing that it’s actually released in August, (but not that confusing, I hope?)

1 Like

You can still do beta/pre-releases when using the calendar-based version. i.e. currently homeassistant has put out 2021.8.0.b1

1 Like

Reply moved here:

1 Like