This time nothing important that is worth mentioning.
5 Likes
So it’s a bump-minimal-version release to screw node operators who can’t use watchtower.
1 Like
Sure. This release stategy is also called scrum. The idea is to have very short release cycles to release as often as possible to screw up as many node operators as possible. 
13 Likes
Yeah, all without communicating to storage node operators.
I recall Storjlings asking what would it take to attract professional sysadmins to maintaining nodes. My answer now is: exactly the opposite of what you’re doing now.
3 Likes
There are bunch of examples with very short release cycles with several releases per DAY.
Storj has plenty of space to speedup their release cycles.
IMHO small and frequent releases are good and easier to support from development stand point comparing to several months per one release. Especially in case of good test automation.
or it’s just a satellite update
Not without communicating the change in schedule to actual operators though.
No communication is needed in case of auto update.
How often you mobile apps updated? I don’t remember any that communicates their updates.
2 Likes
Not everybody can do autoupdate, see my first post.
Please tell me why you can’t use auto-update? I don’t use watchtower either but I have my own script that updates all nodes.
Because watchtower just doesn’t work reliably on my setup for some reason. I do have a script, but I do want to know when to run and supervise it.
Supervised updates are always a problem. I just let my script run every morning at 7am. I’m always at my PC at the time. Every node updates additional 4 hours later. Simple yet effective auto-update that doesn’t screw up all nodes immediately should an error occur.
Yep, same here, except I can do that once a week maybe.
So do it once a week, nothing wrong with that.
Typically not but in the case of the last version (1.28) because you might end up getting no ingress for 5 days because storjlabs skipped a version.
This release is only one version so once a week would be fine.
1 Like
Auto updates are bad for reliability. Every update has potential to break something, so updates should be doen manually or with a script wile watching how that script works.
Also, Storj has stated the update schedule in another thread, but now they apparently jumped by “two versions” according to that schedule.
1 Like
Has the implementation of this version already started?
that being said, there is also some advantages for the project to get up to speed and get everything fine tuned…
i’m not particularly fond of having to update all the time, but sysadmins can also make tools so their update cycle is easier… hmmm this gives me an idea…
hodl my beer…
2 Likes
Note I’m not complaining about speed. I’m complaining about lack of communication of the change.
not sure it’s easy to know which stuff should be communicated or not…
each setup / admin / sno has their own stuff which we consider relevant…
not saying that there is a good simple line of communication from storjlabs, if one just pulls the plug… but hopefully one day we will see something like that baked into the dashboard.
sounds like a feature request right there
why do i always give myself more work lol
i’m thinking something like change logs, maybe some expendable notes about the added or removed features and how’s and why… maybe linking to the online documentation / relevant forum posts…
makes good sense imo to have the most direct line of this sort of communication in the dashboard, then it doesn’t fill up peoples emails and it could trigger a notification on the dashboard every time there is something extra important.
i can tell you that the change (with the release timing) was in fact mentioned in the change logs (on the forum) because i’ve been keeping up with those… and it was mentioned multiple times in change logs and discussed