7.1 isn’t really long term. It is just there as a dummy placeholder until there is an actual long term v7.
Then it should show up as testing:
development: error: file not found.
long term: error: file not found.
Now you are tricked to belive that 7.1 is a stable long term version. Yes I do now that it is not, but other may think so.
I have also lost all routing tables, i was upgrading from first V7 ever released thru all versions until this one and its first time it did something like that..
While it was easy fix by importing back from configuration export i hope it doesnt happen again Mikrotik
..
It is a easy fix but takes a lot of time to do. I rather wait till Mikrotik fix this bug and hope new are created doing so.
Wait a minute… you’re hoping to see new bugs ?
If this was a production router in a company (with 50 routing-marks its not a home router), I would say that it 90% your fault.
- Tesing a RC version in a production environment.
- Not test on an equal router with same OS and Config as the production router.
- With backup, you would only use some minute to downgrade to 7.1.1 and restore your backup. (what you did)
- With 2500+ post you should know better.
In my 30+ year working with network and computing, I have seen many upgrade gone wrong.
Or better yet: PARTITION the router! Copy running version to 2nd partition, upgrade, when it is a disaster: make 2nd partition active, reboot, back in business.
I guess that could not be done to all routers?
Makes it a difference then!? 
If the router goes up in smoke then I rather have backup and an export (off-site). If I can’t get the same router again then I have still the export, to manually copy-and-paste.
@jotne why should I not have that many routing-marks in a home situation. Sorry, I anticipated something utterly stupid going wrong with this ‘RC’ as I wrote in the earlier posting in this tread…and it was.
I had my fare share of hairs turning white because of V7 so I was prepared to overcome any adverse and I could fallback petroleum lighting, and battery power if all went south after the update. 
It is time that Mikrotik is bringing out some kind of survival-kit special made for these kind of situations. Alone a Woobm won’t cut it for non USB routers.
I expected it would go wrong, and it went wrong. It seems, that I have developed a special sense for this and that is why I am still on 7.1.1 and I will be patient as always and see if things happens in the lifespan I still got. No one knows their lifespan up front so it will be a surprise.
My other routers are still on 6.49.x and that is still sufficient for them and they run run and run on it.
Of course you always make a backup, but for the depicted scenario of upgrading a router that is running in production to the next version of RouterOS, using partitioning is the best method.
In the past I encountered the situation where a remote router was upgraded and the new version made it crash. In case of partitioning it automatically switches the partitions and it came back in the old version running from the second partition.
No need to go there and do a netinstall or downgrade.
Most home ruter does only have 16MB, so to use multiple partition you need a larger router with at least 32MB
https://wiki.mikrotik.com/wiki/Manual:Partitions
Yes you need some space. That page is incorrect saying “Partitioning is supported on MIPS, TILE and PowerPC RouterBOARD type devices.”, I have a RB4011 as home router (ARM) and it works there. This device has 512MB of space (a bit of a useless in-between value, too much for a single or dual partition of RouterOS, not enough to do a lot with Docker containers later…).
I see that some of the newly announced devices again have 128MB of flash space. So it seems MikroTik has finally seen the light and provides more than 16MB.
Partitioning also works on ARM64, successfully tested with CCR2004-1G-12S+2XS.
Routing filters seem to not be working in v7.2rc4.
Here they work fine. Do you use the “Set” features? (now renamed to “List”)
(Num Set, Community Set, etc)
- Some problems with switching Wi-Fi networks (different SSIDs on the same router). Hardware (phone, notebook) reports “Network not found”, but on the second try it connects OK. Not happened with 7.1.3.
- Performance a lot better than before (CPU monitoring show normal load at 100 Mbps routing rather than almost full as was before).
Can wireguard/peers current-endpoint and current-endpoint-port be added to winbox/webfig too?
Currently it is only visible with
/interface/wireguard/peers/print detail
Thank you!
rtlx - As many as necessary.
obscurus, noyp - We will look into this.
Ullinator, eworm, blurrybird, loloski - It is fixed, but not in this release. Fix will be included in the next one.
pe1chl, msatter, CTassisF, osc86, IntLDaniel, ivicask - Very sorry for missing routing configuration after an upgrade. We are working on a fix for this.
CTassisF, hecatae, sirbryan, ssbaksa, loloski, memelchenkov- Please send supout file from this router, generated while in the problematic state, to support@mikrotik.com.
MikroTikTack - Thank you for report. We will fix this as soon as possible.
wojo - That is correct. We are working on a fix.
pe1chl, holvoetn - WinBox dependencies are made when it is absolutely necessary. We are not doing this without any reason. Please report problems with WinBox 3.35 to support@mikrotik.com so we can fix them. Without knowing them, we can not fix them.
elgrandiegote - To what changes are you referring to? If you refer to reboots, then they should be fixed in the next release.
buset1974, obscurus, Chupaka - We will look into this.
IntLDaniel - First of all, there is a download archive (https://mikrotik.com/download/archive). Also, you can take a download link from any version and simply edit the version number and platform in the URL.
own3r1138 - The problem with tunnel establishment after a reboot should be fixed. We will look into the problem with DDNS.
sinisa - Additional fixes will be included in the next release.
Znevna - Please provide supout file to support@mikrotik.com when MTU is set to 1480, instead of 1492.
osc86, pe1chl - If you notice such problems, then please report them to us through the official support channel - support@mikrotik.com. Provide examples so we can fix them.
mducharme - There are no direct fixes regarding such an issue. Maybe your problem was resolved by some unrelated fix, which in the end was to blame for the problems that you were experiencing.
realmark - On some very, very, very rare cases on bootup switch chip sometimes was not properly initialized. We fixed this problem.
manojlovicl - We are trying to reproduce this problem but at the moment no luck. Can you provide supout file from your server to support@mikrotik.com? Make sure that you generate file while duplicate sessions are present on the router.
gittubaba - You do not need to wait for long. Soon it is coming back.
raymondr15 - Please provide examples of rules that are not working properly to support@mikrotik.com.
Znevna - Will be added in the upcoming releases.
Everyone - there was no and is no a simple and perfect way how to transition from v6 to v7. We do consider this the least harmful way. We will slowly transit versions between channels until we reach a state when v7 has two reliable version trees (long-term and stable) and one for testing purposes (testing). It will take a while and many RC and beta versions are yet to come. Also, nobody is obligated to upgrade. If you are just fine with an older version, then you can simply wait for a while or try out upgrades on test setups - this is completely up to you.
Thanks Mikrotik!
We are eagerly awaiting the next RC with the bug fixes.