New Release Policy

Audio Gear Talk RoPieee
1

The first release of this year was for sure not the prettiest one. So I reflected a bit on what caused it, and what I can do to prevent it (as much as possible) from happening again.

Bottom line: it comes down to too little testing, especially with all the possible combinations of RoPieee units possible. And to be honest: as this is a ‘spare time project’ (which I don’t have :wink: ), testing stuff is by far the least fun part in developing RoPieee.

So, I need your help. Starting from now, a new RoPieee release will first be released on the beta channel, in full. That means for all supported platforms, without exception. It comes with changelog, and is the next release; it is not an experimental build or something like that.

From the moment the release is available on the beta channel we simply take some time to gather evidence that everything is ‘green to release’. So if there are enough people willing to join the beta unit with one or more units, we can make sure all possible combinations of RoPieee are covered and tested.

When I consider the ‘evidence’ to be strong enough (combination of time, number of ‘thumbs up’ and enough variations in RoPieee platforms), then I’ll push the update to the stable channel.

Is this airtight?
No it isn’t. But it can make it almost, especially considering the limitations (this being a spare time project etc.)

Will this slow down RoPieee development?
No. Certainly not. It will only slow down the next release, when we start taking the ‘beta channel route’. After that we’ll get in a rhythm, where a stable release will be followed rather quickly with the next beta, with the same pace as up until now.

Is it safe for me to do this on my daily ‘production’ RoPieee unit?
I’ll leave that choice up to you. But considering that a beta release is a release candidate, it should be pretty safe (not thinking about the January release right now).

Is this a shortcut for me to be asking for specific features?
No it’s not. This is just like a regular release as we know up until now, only it has been ripening for some time.

If this is not scaring you off then this might be something for you. With the next/first release (which is coming soon) I’ll provide some info on what to do.

Thanks in advance!

30 Likes
2

I’m in!
Since you’re doing this for all of us, we should help you, I’ll be following this thread to see when we’re going live with testing…

1 Like
3

I’m not (yet) a RoPieee user so I have ‘no skin in the game’ so to speak but I do appreciate the efforts of you and others like you who put their time and effort into such projects. Thankyou.

I absolutely see the need for you to do something along these lines. I know from experience that testing very quickly becomes a huge burden.

However, it may be worth spelling out how you would expect to handle the case when the ‘beta’ release was (heaven forbid) found to be defective for some reason.

Would that beta release simply get replaced with a new beta release or do you have some other strategy in mind? Or even one of several strategies based on the nature of the fault?

1 Like
4

Harry, I am in. I’ll dedicate one of my Pi3 display / Pi3 Hat pairs to this.

1 Like
5

I’ve got enough devices to have a few in the beta channel for sure. So count me in Harry.

1 Like
6

I’m in too !

1 Like
7

I’m in too. But let’s hope that not everybody does the same or you’ll be back where you started :slight_smile:

1 Like
8

I am in. You are the man @spockfish and whatever I can do to help.

1 Like
9

I’ll applaud to that - good idea it is!!

1 Like
10

I’m in.
I will put two “spare” units (RPi4s) in play to help with this, too.
It’s time to retire the RPi2 anyway… :slight_smile:

1 Like
11

Thanks. I’ve moved over to the Beta channel.

1 Like
12

Dear @spockfish - RoPieeeXL 2023.11 (1188) with usbridge signature works perfectly, but new release 2024.01.1 [1295] has problem with 50% of Qobuz 96kHz files played over UPNP. Sound quality on others is absolutely amazing, but half of 96kHz files stops after a few seconds. I was using a few different softwares but now Im very satisfied with Ropieee 2023.11 sound quality :slight_smile:

1 Like
13

Wow, I am not a RoPieee user up to now, but when I see the commitment here and the style of you guys communicating with each other I might very well become a user. Looks like a great community to me.

8 Likes
14

Sounds like a good plan to me.
Just made another donation to help cover your time.

3 Likes
15

Hi, ignoring if there is a specific thread for new features, I’d like to share some wishes which could dramatically improve Ropieee’s sound quality.

  1. Having experienced the great benefit in fixing the CPU frequency to a low level activity on a SOtM SMS 200 Ultra, I was thinking that this could benefit as well the PI platform. Instead of using a variable speed governor setting, could you provide a CPU frequency selector where all available (and viable… too low is messy) multiples would be selectable by the end user and one would select the lowest stable one depending on the needed bitrate, ending with a fixed frequency running PI, having lower noise ingested to the DAC.

  2. It would also be interesting to have a kind of diag page where most common OS KPIs would be available. In particular the CPU load, the network negotiated speed and flow control, and the DAC negotiated capabilities (PCM and DSD)….

In any case, Ropieee is a great piece of work…. Thank you :pray:

1 Like
16

Please keep it simple. Thanks.

1 Like
17

@spockfish Harry I have a couple that would not be too hard either I hope. Ideally setting in the web interface.

For the clock display a 2 brightness setting option for what’s good day/evening time (ie when I’m up and about full brightness) is ideal. And a night mode window like dim enough not to light up a bedroom when trying to sleep but on to normal again when it’s daylight so I can see the clock again and what’s playing. Could be combined with a colour change option for both modes…like the iPhone night stand does when it’s lighter in the room and when it’s dark, but time window based.

Also on the clock subject a time of day on the playing display or better yet an option to display the time for most of the track but show the track screen for a set delay when a new track starts (or maybe a volume change) so one can take a look at an unfamiliar song but still be able to benefit from the clock for the remainder of the track.

18

Wrong place to post such here… :wink:
Belongs to [Release 2024.01.1]
(Release 2024.01.1 - #71 by Paul_Kwan)

19

Great idea and as i have two identical hardware setups I can move one to the beta channel @spockfish . However I have an idea as well - could you (we?) find a way of documenting what hardware combinations are in use on the channel (do you record the update downloads - do you get an installed base count?). So that we could look for our combination at the website and infer confidence to update.

Clearly if you don’t currently collect installed hardware data this isn’t going to fly - but maybe it would be useful for future development decisions?

Thanks, Peter

20

I’m in for certain, happy to assist in any way I can.

Cheers,

Mark