Yes there was a v1.23 release. We used it to iterate quickly towards migrating the old satellites to the new multipart upload code base. That was executed on SLC and allowed us to discover and fix a few bugs. Over the next few weeks we are going to migrate all satellites.
In general this can always happen. When it comes to deployments my biggest concern is that we screw up the satellite migration or the rolling upgrade. There is room for a bunch of errors that our unit tests wouldn’t cover. We do have a rolling upgrade test in place. That test is sensitive for version numbers. In order to get accurate test results we sometimes have to push a new release. With a point release we might bypass the rolling upgrade test and that can have some very bad consequences.
Do you happen to know what the contents/format of the receipt field would be for zkSync payouts. I’m going to have to make some adjustments for this in the earnings calculator but haven’t switched to zkSync myself yet, so I would need an example.
Edit: Never mind, found it. Prefix will simply be zksync instead of eth. Simple enough. Looks like I’ll also be removing some warnings as there is a database migration included to fix missing distributed amounts for stefan-benten. Nice! That’ll clean up some historic misreporting.
that makes no sense…that version number has always been much lower than what this announcement told us was the lowest version else we would get DQ.
even when the post was made only 4 months ago… how are we suppose to know what do when the information given out in such a short timeframe is conflicting.
so we should just disregard what that post says?
and why would it even be written if it was wrong at the time it was written, was it just suppose to inform us about that version DQ was turned on… and the version thing is just how it will become at one point…
Today I Learned that the 1.13.0 in the version mouseover is the minimal allowed to join the network. Would still like to see the minimum to receive ingress (currently 1.22.2) included in the mouseover.
Any time I’ve been below the “storagenode: minimum: version:” listed in https://version.storj.io/ my ingress has flatlined, and I’ve been told I need to update to be properly taking part. Not sure how you’re working or if my understanding is incorrect.
I’m with @SGC on this one I must say, I’m very confused what versions disqualify nodes or not considering that hovering the version on the dashboard shows Running the minimal allowed version: 1.13.0: That is way more than 3 minor versions behind!
I don’t know what Storj’s specific reason for drawing the lines where they have, but it is pretty standard for software vendors to require a certain minimum version for support. Known bugs, incompatibility with newer network features, etc. could be valid reasons to require being on a more recent version.
I’m glad somebody brought up the question of minimum versions, I was going to ask about that. It is unclear how to get disqualified by just 1 version number.
A great and simple thing would be to simply show all the info on version tooltip.
“Latest software version is: vx.y.z
Limited ingress below this version: vx1.y1.z1
Node disqualification below this version x2.y2.z2”
It would be even greater if the color of the version number would change. Like green if version is up to date, yellow and orange if updates have been missed, red if no ingress anymore and maybe black if below minimum or something like that.