Option to revert to the previous version of Zwift

Any time Zwift is updated and a new spectacular bug is introduced, so hundreds or thousands of people are unable to run Zwift, I miss the possibility to revert to the previous version and/or put the update on hold until the bugs are resolved (“zoon”).

Such a feature would be super useful, e.g. if you want to attend a TTT and the team is waiting for you in the Pen…

Agree 100%. Also the option to simply not update when the splash screen comes up would be a massive improvement, especially when the update is nothing more than a new trainer (that most people don’t have anyway) being added or a new frame in the garage but nothing functional

1 Like

I think the problem with this ask , which is a good ask , is that I dont think Zwift is coded to support release versioning compatibility at all . Ever release even when it is nothing at all is technically a “major release” and you are by necessity forced to update or infact you WILL get unexpected and compat issues for sure .

Yeah you’re probably right about that. This is a bugbear for me with a lot of software though, not just Zwift.

Yes its an “expensive” thing to build into your product strategy and as such often gets marked down as nice to have but not critical ( e.g. not going to get adopted ) . Then releases go out that cause very expensive issues with loss of critical brand reputation and even customer headcounts and the decision sometimes gets questioned but it is a very mature business indeed that can make this one stick as a strategy.

That said I think Zwift could do with pulling there socks up a wee bit at least on this , and would be surprised if there was not a lot of internal barking going on suggesting they should already JFDI , its whether that comes with the required support and backing in the form of an agreed approach that senior stakeholders stick too even when its not “convenient” that matters.

There does have to be an EOL strategy though and I think for a product like Zwift that does have to be quite short in many aspects just think that monthly is probably too short and too much risk . They should seperate out those changes that definately EOL … just as changes to how a user might experience performance from those that are more “optional” basis … such as a new bike or jersey , hey we can live with not having that for a week or so , if by having it I am riding in a black hole upside down or floating in the air somewhere .

Problem with this is that the entire premise of the game is that we’re all riding in the same world(s) at the same time, which should mean with the same maps and same feature set. It may not be apparent but the maps are quietly updated all the time, it can be seen in the patching logs. Tons of people being on an older version than current is already a big enough problem as it is, even without newly introduced bugs. The last thing they’d want to do is to be seen to encourage people not to update or to go backwards.

The best solution if you want to actively avoid or defer updates* is to use a platform that allows it, i.e. everything except PC and Mac.

*without messing about with the launcher

2 Likes

Sorry I edited the post as you were replying . There are some changes for sure that would be immediate EOL but again this month for example . Given the choice of a couple of new bikes or viewing a black screen I think I would choose to forgo access to the new bikes until the screen was viewable again . So there is scope to be more dynamic with EOL releasing. .

Here is another example , an update is made to London Map . So client versions required to ride London is now version N+1 . However this release also causes my Trainer to not register at all . The best way to sort this is to allow me to continue to ride version N (i.e be able to use the service ) but get a , you cant access London map without upgrading to N+1 message . Its not perfection , nothing is . But its a lot better than just either it works or talk to the hand .

Well that’s why a release which breaks the game so badly should never see the light of day, as discussed in the other thread. Clearly nobody should have to make that choice. If there was a brief ‘known issues’ list as I suggested, people on said platforms could make their own minds up whether to update immediately or not. I just don’t see Zwift ever offering rolling back as a feature, and rightly so IMO.

100% bug free releases has never been achieved ever , cant see it happening . However tagging required version dependency to access features is pretty well adopted process that is certainly possible to support and means no one has to either update or install something they wont want to ever access .

I think in the long run also Zwift are going to have to tackle this , because otherwise there product is going to be dictated to by least common denominator of client capability . Sooner or later they will want to support features more easily that simply wont work for large numbers of users .