1.8 changes the method for storing item in inventory chests and all other container objects.
1.7 and older versions use the old familiar block id method. This makes 1.8 generated worlds fundamentally incompatible with older versions: :"How so?" you may ask. You can easily open your 1.8 world with an older version of of minecraft, (as I have accidentally done twice now) resulting in the complete erasure of everything you own. Of course when you exit minecraft the world is saved and your now nearly back to day 1, broke, but with a nicer house.
To me it seem inexcusable that there is no warning when opening a 1.8 map with an older version when such a fundamental incompatibility exists. This is nothing to do with snapshots but is a long standing problem. How hard could it be to add a simple warning "Incompatible map. Are you sure you want to proceeding?" Yes I know I can make backups, but do you back up every time you play?
This is not a bug it's a long standing design flaw in the map selection interface. No program I use lets you open a file with an older version of the program. The launcher lets you revert back to any previous version of Minecraft, but does not provide even the most basic compatibility check or warning before you trash your world.
The item storeage changes in 1.8 make the damage to your worlds even worse.
Edit: I decided to add what I think is a simple permanent solution that they could easily implement in a day.
Proposal for a permanent solution. (1.8.1 / 1.9 etc)
1. Currently all maps are maps are stored in minecraft/saves
2. When a new world is created, save it in a folder with a name based on the version that created it.
Example: 1.8.1 would use something like minecraft/saves/010801/.... = my 1.8.1 maps
Example: 1.8.2 would use something like minecraft/saves/010802/
3. When you view the Maps Selection screen, it only displays maps for the version you are using OR older. When you open and old map with a new version it gets physically moved to the new folder before opening. In this way, updates are 1 way.
4. When you select an older profile (like 1.7.10 or older), that version of the program ignores the files in /010801/
so corrupting your new or updated worlds is no longer possible.
5. If you really really want to open the map in an older version again, you just copy it back.
6. Using the folder names based on the version that created it would allow the map selection screen to display version numbers for new maps going forward.
Conclusions: Separate folders is the method already used for program versions management, so it not re-inventing the wheel at all. I'm an experienced programmer so I can tell you this is 8 man hours of work for them to save thousands of worlds from accidental corruption with the loss of tens of thousands of man hours of player work.
If I may ask, why are you trying to back-load versions of the game on the same map? When has that ever been a good idea, especially without backing anything up beforehand?
Your right it a TERRIBLE idea. I play on several servers running various versions of minecraft so switching profiles is something I do every day. Last night I checked in on my favorite server running 1.7.10. Today I started up my single player map and failed to notice I did not switch back to 1.8 snapshots.
For something that is so easy to do that's so obviously a bad idea, How hard would it be have a simple warning?
"This map was created with version x.x Your running version y.y Are you sure you want to proceed? [Yes] [No]
Rollback Post to RevisionRollBack
Please actually read posts before responding, so you don't end up looking stewped.
The fact that it's a snapshot alone should be enough warning. Mojang is busy developing 1.8. They can't go in and add a warning for every possible bad outcome that could result in loading into another version. To expect that is ridiculous. These are purely for TESTING PURPOSES. It's never recommended to load crucial data into a "beta" version of software, and that's true outside of Minecraft. You should have known better and backed up your world.
Rollback Post to RevisionRollBack
"Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover." §7- Mark Twain
The fact that it's snapshots really doesn't mean anything- once we get to 1.8 official release, it'll still be the same situation. People will have servers that have yet to update to 1.8, switch back to 1.7, then open their 1.8 worlds forgetting they're not currently in 1.8, and then their world's screwed up. Yes, making regular backups solves this, but it's no excuse for it being possible to do this without even knowing you did anything wrong until it's too late. The problem is not that the user made a mistake, the problem is that the mistake is possible without warning in the first place, so the best solution is what the OP suggests, along with a marker near the world's name stating what version it was last updated in. Then, if people STILL break their worlds, it's THEIR fault, but currently, it's not really.
If I may ask, why are you trying to back-load versions of the game on the same map? When has that ever been a good idea, especially without backing anything up beforehand?
Are you kidding ? Forgetting to switdch to the proper version is a very easy mistake, especially when you have situations like:
- People with below average (or even human-average) memory.
- Multiple worlds you play which each need a different version for some readson. It may be the mod you use on a specific world which doesn't support the latest release yet, and in some other world you play latest release. Or it may be because you like a world to have some worldgen feature that apply only to that (older) version, for example huge oceans don't exist anymore starting from 1.7, so you might like to keep a 1.6.4 world around, while in another world you play the latest version.
- Several players playing using the same account and some of them can't be expected to do things perfectly right all the time, like say if your young kid also plays Minecraft on your computer.
etc.
Using profile name + version number, a detailed "Aare you sure ?" warning screen with Back/Proceed buttons of some kind, would help a lot to avoid stooopid easy mistakes. Blocking a player from being able to play a world at all for some version incompatibility is one thing, but forever destroying his inventory is quite another.
From first principles, probably not too hard. Adding it after the fact? Not so easy.
First, the warning would have to be in 1.7 to be any good. Which means a 1.7.11. And given the typical scenario- a Server not updated to 1.8 yet and a user rolling back to the server version, and given the length of time it often takes for servers to update even through minor versions, It's unlikely they would be rolling back to an imagined 1.7.11 version that has such a warning. They would be rolling back to 1.7.10, which doesn't have said warning and thus nothing has been resolved. 1.7.10 and earlier, the present, latest versions, cannot have this added to them.
And what if a server happens to be running 1.6.4, or 1.5.2 for whatever reason? rolling back to any of those versions would cause the same issue.
The "oops I accidentally loaded my world in an old version" has been common for quite some time and is a brain fart. I've done it myself. Thing is, it's preventable through simple means- you can simply make a backup. It can be "fixed" for future versions, (eg 1.8 opening a supposed 1.9 world) but at that point, there is no major damage. The issue that you want addressed is opening 1.8 worlds in 1.7, and the only suggestion I would have is to set up your profiles so that it's not possible. If your 1.7 profile is set to a different save folder than your 1.8/main world, you can never open your 1.8 worlds in 1.7 by accident. Instead of requiring the game/software to prevent this sort of problem, take your own steps to prevent it, particularly since any useful implementation of this sort of thing can literally never exist since it would require a time machine to go back and change the released versions of 1.7.10 (and heck all of them- some servers are still on 1.7.4).
unfortunately i have also experienced this. i was playing in the newest snapshot (14w32b) and when it loaded (ill also add the world i was playing in was a world where i was trying to complete all achievments), my achievments were re-set, and the achievement pane stopped and getting iron and cooking a fish. so that pissed me off, and when i went into my storage room, all of my chests were invisible. now i was unaware that any 1.8 world was incompatable with 1.7 worlds because there isnt any warning whatsoever about such a problem existing, so i figured i would load the world in 1.7.10 and see if the achievement pane would go back to where it was. i loaded it in and absolutely everything is gone. all my levels items even what was in my furnaces is obliterated. i find it to be absolutely outrageous that mojang lets you play in these snap shots and gives you no warning about any problems that might exist. so now that world is ruined for me and ill have to start all over in a new world. i think mojang needs to get it's head in the game and if they are going to put out these experimental snap shots, they should tell you all the problems that the snapshots might cause
Your right it a TERRIBLE idea. I play on several servers running various versions of minecraft so switching profiles is something I do every day. Last night I checked in on my favorite server running 1.7.10. Today I started up my single player map and failed to notice I did not switch back to 1.8 snapshots.
For something that is so easy to do that's so obviously a bad idea, How hard would it be have a simple warning?
"This map was created with version x.x Your running version y.y Are you sure you want to proceed? [Yes] [No]
Are you kidding ? Forgetting to switdch to the proper version is a very easy mistake, especially when you have situations like:
- People with below average (or even human-average) memory.
- Multiple worlds you play which each need a different version for some readson. It may be the mod you use on a specific world which doesn't support the latest release yet, and in some other world you play latest release. Or it may be because you like a world to have some worldgen feature that apply only to that (older) version, for example huge oceans don't exist anymore starting from 1.7, so you might like to keep a 1.6.4 world around, while in another world you play the latest version.
- Several players playing using the same account and some of them can't be expected to do things perfectly right all the time, like say if your young kid also plays Minecraft on your computer.
etc.
Using profile name + version number, a detailed "Aare you sure ?" warning screen with Back/Proceed buttons of some kind, would help a lot to avoid stooopid easy mistakes. Blocking a player from being able to play a world at all for some version incompatibility is one thing, but forever destroying his inventory is quite another.
Or you can simply save the worlds in a different directory...
This is NOT because of the snapshots! Stop blaming people for playing a snapshot then somehow reverting back to an official release.
Even with "official releases" there is NO warning and NO way to know which version of Minecraft created a map and which ones might have subsequently loaded it.
level.dat already includes a version number. It was added when they made the changes to the block data that made it clear such metadata would be useful. There doesn't appear to be any prompt if the number is higher. Hopefully that get's added before it is actually released.
Adding it to 1.7.10 and earlier is impossible to do in any way that would allow it to be very useful- at least, not without a time machine.
An easy solution is to prevent older versions from even seeing 1.8 worlds; one way is to change the NBT version in level.dat, which the game uses to identify the format used; this is why very old worlds (MCRegion instead of Anvil) will have a "must be converted" message under their name. I even tested this; changing it to 19134 (19132 is MCRegion and 19133 is the current Anvil format) prevented the game for seeing the world, modding the game to use 19134 instead of 19133 to identify Anvil worlds allowed it to see the world again, although it no longer saw normal worlds, but they could just as easily do what they did when they first changed the NBT version (when you convert a MCR world it even makes backups of level.dat and the region files).
This is also a good opportunity to change block IDs as well; I suspect that they have been holding back on changing block IDs from numeric values because of how catastrophic it would be to load such a world in an older version (think missing items is bad? Try loading your world and falling into the void because, well, everything is gone). Of course, it would be awfully inefficient to store every block as a string, which is why a lookup table should be added (also a good idea for item IDs). A lookup table can also be used to alert the user that an item/block is missing if they try to play a world without a mod installed, similar to Forge, which makes a list of each item/block present in the mods used and warns you if they are missing.
The fact that it's snapshots really doesn't mean anything- once we get to 1.8 official release, it'll still be the same situation. People will have servers that have yet to update to 1.8, switch back to 1.7, then open their 1.8 worlds forgetting they're not currently in 1.8, and then their world's screwed up. Yes, making regular backups solves this, but it's no excuse for it being possible to do this without even knowing you did anything wrong until it's too late. The problem is not that the user made a mistake, the problem is that the mistake is possible without warning in the first place, so the best solution is what the OP suggests, along with a marker near the world's name stating what version it was last updated in. Then, if people STILL break their worlds, it's THEIR fault, but currently, it's not really.
This is true, but it has been the case in the past as well. If you open up a 1.7 world in 1.6 by accident you will experience plenty of problems and blocks / items being deleted. The simple rule of thumb is that opening a world saved in a newer version in an old version is never a good idea unless the two versions are explicitly compatible, like 1.7.9 and 1.7.10 or something.
The core issue is, as you said, the fact there is no compatibility check at world load. That sort of thing should have been added back in alpha, but it is never too late, if they added such a feature in a 1.7.11 update and then 1.8 it would cover the majority of players before long.
This isn't even a complicated thing to do, just save a "most recent version" field in the savegame and prompt the user if that field has a newer version string than the running game does. Of course a simple comparison and parsing logic wouldn't always stop the game, or needlessly stop it if two versions really are compatible, there would need to be a special version registry that maps information to each version, like compatibility groups for example, that the game can use for more advanced compatibility checks.
This isn't even a complicated thing to do, just save a "most recent version" field in the savegame and prompt the user if that field has a newer version string than the running game does. Of course a simple comparison and parsing logic wouldn't always stop the game, or needlessly stop it if two versions really are compatible, there would need to be a special version registry that maps information to each version, like compatibility groups for example, that the game can use for more advanced compatibility checks.
"This isn't complicated if you do it this complicated way!"
Are you kidding ? Forgetting to switdch to the proper version is a very easy mistake...
It's an easy mistake to make, but also one that can be very easily prepared for. If several players are using an account, or if mods are being used on one or more profiles, then I have no sympathy for those without the foresight to back up their save files regularly. When it comes to PC gaming, and especially when it comes to messing with mods and updates on PC games, backing up save files is a necessity, and if that's a hard learned lesson, so be it.
I still stand by my original premise, however: Going back in time with updates on any game has never been a sound idea, and always presents some challenges, and ones developers are unlikely to fix because, at the end of the day, it isn't really their problem. Players choose to roll back the updates on existing save files from more recent versions of the game, and players need to be self-aware of their actions any time game data is changed like that.
"This isn't complicated if you do it this complicated way!"
Complexity is pretty relative, I don't find this task list very complicated:
1. Get game version
2. Get savegame "CurrentCompatibilityGroup" field (or whatever it would be called)
3. Query a database or list for the game version and get its compatibility group
4. if (savegame_compatibility_group > game_compatibility_group)* prompt user, else continue normally
* It is assumed that newer (not necessarily in a date/time sense) versions always have a larger group value than older versions
And of course in the world saving logic:
1. Get game version
2. Get its compatibility group from the database or list
3. Write the value into the compatibility group field
Of course it could be problematic to do version compatibility groups for interleaved developments like r1.7.x and 1.8 snapshots and not break that assumption, since 1.8 snapshots can be released before a 1.7 version but still be "newer" technically, but if you choose appropriate values you could get away with it, such as the first 1.7 snapshot having a group value of 17000 and 1.8 snapshots 18000, etc. That's 1000 compatibility groups reserved for a single version branch.
The idea is fairly simple really, if you are a programmer. Hell you could save the compatibility group directly in the game like its version and completely skip the database/list step. The more tricky part would be covering any edge cases that might occur, and of course my idea might very well be flawed in some regard and need a bit of tuning.
I don't really understand why there'a so much opposition to this idea.
"...but the player already receives a warning to back up before getting snapshots!"
Sure, but does anyone back up every single time they open the game? It takes a good minute to back up with a large world size.
"Store worlds in a different directory!"
This can work, admittedly. Still, it requires twice the hard drive space.
Here's the thing. A basic warning message would take five minutes to implement, and a "good" system would take about an hour. Given how much grief accidental downgrading has caused (just count the "I lost all my items" threads in the past few months), Mojang should just implement a quick fix, even if none of the mishaps are technically their fault.
Rollback Post to RevisionRollBack
If you found my post helpful, please click that green up arrow over there!
It's an easy mistake to make, but also one that can be very easily prepared for. If several players are using an account, or if mods are being used on one or more profiles, then I have no sympathy for those without the foresight to back up their save files regularly. When it comes to PC gaming, and especially when it comes to messing with mods and updates on PC games, backing up save files is a necessity, and if that's a hard learned lesson, so be it.
I still stand by my original premise, however: Going back in time with updates on any game has never been a sound idea, and always presents some challenges, and ones developers are unlikely to fix because, at the end of the day, it isn't really their problem. Players choose to roll back the updates on existing save files from more recent versions of the game, and players need to be self-aware of their actions any time game data is changed like that.
As I said before, just ignoring the issue and blaming the player won't solve the underlying issue, because people not making backups is not the cause of their worlds getting corrupted due to their inattentiveness. Rather, it's because it was possible at all. Thus, the solution becomes not blaming the end user, but making it so loading a world in an older version is impossible to do on accident. (But please, allow it to be done on purpose so we can purposefully corrupt our worlds for enjoyment to see what may happen!)
I still stand by my original premise, however: Going back in time with updates on any game has never been a sound idea, and always presents some challenges, and ones developers are unlikely to fix because, at the end of the day, it isn't really their problem. Players choose to roll back the updates on existing save files from more recent versions of the game, and players need to be self-aware of their actions any time game data is changed like that.
Some times people have to do that though. My survival world is 14w31a currently and I always use that version for my worlds, but some times I need to use 1.7.10 to play on a server I run with my friend. More than once I just completely forgot to change the game profile in the launcher after playing on the server and often didn't remember until I was already loading the world or saw my empty inventory. The Game Directory thing in the launcher is one solution that I have since taken advantage of, but it is not a very intuitive one for the casual everyday user. Of course it is on my hands to get brain-farts, but is it unreasonable of me as a user to expect the software to handle this very possible scenario gracefully so that I don't have to exit the game and restore the backup?
The key principle of usability is that the user shouldn't have to think or be concerned with software quirks. To make another example, suppose Mojang never added a horizontal collision system to the game, would it be their responsibility to add the collision system or would it be the user's responsibility to be aware of this limitation and actively not walk through the walls? It is an extreme analogy of course but does bring home my point. I am a software developer myself and I personally think developers should do as much as they can within reason to protect users from themselves and their brain-farts and limited technical skills. This specific case is a very reasonable and quick one to address and by now could have saved god knows how many worlds from oblivion, the benefit is obvious.
1.7 and older versions use the old familiar block id method. This makes 1.8 generated worlds fundamentally incompatible with older versions: :"How so?" you may ask. You can easily open your 1.8 world with an older version of of minecraft, (as I have accidentally done twice now) resulting in the complete erasure of everything you own. Of course when you exit minecraft the world is saved and your now nearly back to day 1, broke, but with a nicer house.
To me it seem inexcusable that there is no warning when opening a 1.8 map with an older version when such a fundamental incompatibility exists. This is nothing to do with snapshots but is a long standing problem. How hard could it be to add a simple warning "Incompatible map. Are you sure you want to proceeding?" Yes I know I can make backups, but do you back up every time you play?
This is not a bug it's a long standing design flaw in the map selection interface. No program I use lets you open a file with an older version of the program. The launcher lets you revert back to any previous version of Minecraft, but does not provide even the most basic compatibility check or warning before you trash your world.
The item storeage changes in 1.8 make the damage to your worlds even worse.
Edit: I decided to add what I think is a simple permanent solution that they could easily implement in a day.
Proposal for a permanent solution. (1.8.1 / 1.9 etc)
1. Currently all maps are maps are stored in minecraft/saves
2. When a new world is created, save it in a folder with a name based on the version that created it.
Example: 1.8.1 would use something like minecraft/saves/010801/.... = my 1.8.1 maps
Example: 1.8.2 would use something like minecraft/saves/010802/
3. When you view the Maps Selection screen, it only displays maps for the version you are using OR older. When you open and old map with a new version it gets physically moved to the new folder before opening. In this way, updates are 1 way.
4. When you select an older profile (like 1.7.10 or older), that version of the program ignores the files in /010801/
so corrupting your new or updated worlds is no longer possible.
5. If you really really want to open the map in an older version again, you just copy it back.
6. Using the folder names based on the version that created it would allow the map selection screen to display version numbers for new maps going forward.
Conclusions: Separate folders is the method already used for program versions management, so it not re-inventing the wheel at all. I'm an experienced programmer so I can tell you this is 8 man hours of work for them to save thousands of worlds from accidental corruption with the loss of tens of thousands of man hours of player work.
Please Support.
For something that is so easy to do that's so obviously a bad idea, How hard would it be have a simple warning?
"This map was created with version x.x Your running version y.y Are you sure you want to proceed? [Yes] [No]
Are you kidding ? Forgetting to switdch to the proper version is a very easy mistake, especially when you have situations like:
- People with below average (or even human-average) memory.
- Multiple worlds you play which each need a different version for some readson. It may be the mod you use on a specific world which doesn't support the latest release yet, and in some other world you play latest release. Or it may be because you like a world to have some worldgen feature that apply only to that (older) version, for example huge oceans don't exist anymore starting from 1.7, so you might like to keep a 1.6.4 world around, while in another world you play the latest version.
- Several players playing using the same account and some of them can't be expected to do things perfectly right all the time, like say if your young kid also plays Minecraft on your computer.
etc.
Using profile name + version number, a detailed "Aare you sure ?" warning screen with Back/Proceed buttons of some kind, would help a lot to avoid stooopid easy mistakes. Blocking a player from being able to play a world at all for some version incompatibility is one thing, but forever destroying his inventory is quite another.
From first principles, probably not too hard. Adding it after the fact? Not so easy.
First, the warning would have to be in 1.7 to be any good. Which means a 1.7.11. And given the typical scenario- a Server not updated to 1.8 yet and a user rolling back to the server version, and given the length of time it often takes for servers to update even through minor versions, It's unlikely they would be rolling back to an imagined 1.7.11 version that has such a warning. They would be rolling back to 1.7.10, which doesn't have said warning and thus nothing has been resolved. 1.7.10 and earlier, the present, latest versions, cannot have this added to them.
And what if a server happens to be running 1.6.4, or 1.5.2 for whatever reason? rolling back to any of those versions would cause the same issue.
The "oops I accidentally loaded my world in an old version" has been common for quite some time and is a brain fart. I've done it myself. Thing is, it's preventable through simple means- you can simply make a backup. It can be "fixed" for future versions, (eg 1.8 opening a supposed 1.9 world) but at that point, there is no major damage. The issue that you want addressed is opening 1.8 worlds in 1.7, and the only suggestion I would have is to set up your profiles so that it's not possible. If your 1.7 profile is set to a different save folder than your 1.8/main world, you can never open your 1.8 worlds in 1.7 by accident. Instead of requiring the game/software to prevent this sort of problem, take your own steps to prevent it, particularly since any useful implementation of this sort of thing can literally never exist since it would require a time machine to go back and change the released versions of 1.7.10 (and heck all of them- some servers are still on 1.7.4).
Or you can simply save the worlds in a different directory...
CLICK FOR BEST SUPPORT WEBSITE EVER!
Make sure to click the reply or quote button on my post if you are replying to me, otherwise it is unlikely that I will see your post.
If you follow your heart, it will only lead to your arteries.
If you follow your heart, it will only lead to your arteries.
level.dat already includes a version number. It was added when they made the changes to the block data that made it clear such metadata would be useful. There doesn't appear to be any prompt if the number is higher. Hopefully that get's added before it is actually released.
Adding it to 1.7.10 and earlier is impossible to do in any way that would allow it to be very useful- at least, not without a time machine.
This is also a good opportunity to change block IDs as well; I suspect that they have been holding back on changing block IDs from numeric values because of how catastrophic it would be to load such a world in an older version (think missing items is bad? Try loading your world and falling into the void because, well, everything is gone). Of course, it would be awfully inefficient to store every block as a string, which is why a lookup table should be added (also a good idea for item IDs). A lookup table can also be used to alert the user that an item/block is missing if they try to play a world without a mod installed, similar to Forge, which makes a list of each item/block present in the mods used and warns you if they are missing.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
This is true, but it has been the case in the past as well. If you open up a 1.7 world in 1.6 by accident you will experience plenty of problems and blocks / items being deleted. The simple rule of thumb is that opening a world saved in a newer version in an old version is never a good idea unless the two versions are explicitly compatible, like 1.7.9 and 1.7.10 or something.
The core issue is, as you said, the fact there is no compatibility check at world load. That sort of thing should have been added back in alpha, but it is never too late, if they added such a feature in a 1.7.11 update and then 1.8 it would cover the majority of players before long.
This isn't even a complicated thing to do, just save a "most recent version" field in the savegame and prompt the user if that field has a newer version string than the running game does. Of course a simple comparison and parsing logic wouldn't always stop the game, or needlessly stop it if two versions really are compatible, there would need to be a special version registry that maps information to each version, like compatibility groups for example, that the game can use for more advanced compatibility checks.
"This isn't complicated if you do it this complicated way!"
It's an easy mistake to make, but also one that can be very easily prepared for. If several players are using an account, or if mods are being used on one or more profiles, then I have no sympathy for those without the foresight to back up their save files regularly. When it comes to PC gaming, and especially when it comes to messing with mods and updates on PC games, backing up save files is a necessity, and if that's a hard learned lesson, so be it.
I still stand by my original premise, however: Going back in time with updates on any game has never been a sound idea, and always presents some challenges, and ones developers are unlikely to fix because, at the end of the day, it isn't really their problem. Players choose to roll back the updates on existing save files from more recent versions of the game, and players need to be self-aware of their actions any time game data is changed like that.
Complexity is pretty relative, I don't find this task list very complicated:
1. Get game version
2. Get savegame "CurrentCompatibilityGroup" field (or whatever it would be called)
3. Query a database or list for the game version and get its compatibility group
4. if (savegame_compatibility_group > game_compatibility_group)* prompt user, else continue normally
* It is assumed that newer (not necessarily in a date/time sense) versions always have a larger group value than older versions
And of course in the world saving logic:
1. Get game version
2. Get its compatibility group from the database or list
3. Write the value into the compatibility group field
Of course it could be problematic to do version compatibility groups for interleaved developments like r1.7.x and 1.8 snapshots and not break that assumption, since 1.8 snapshots can be released before a 1.7 version but still be "newer" technically, but if you choose appropriate values you could get away with it, such as the first 1.7 snapshot having a group value of 17000 and 1.8 snapshots 18000, etc. That's 1000 compatibility groups reserved for a single version branch.
The idea is fairly simple really, if you are a programmer. Hell you could save the compatibility group directly in the game like its version and completely skip the database/list step. The more tricky part would be covering any edge cases that might occur, and of course my idea might very well be flawed in some regard and need a bit of tuning.
"...but the player already receives a warning to back up before getting snapshots!"
Sure, but does anyone back up every single time they open the game? It takes a good minute to back up with a large world size.
"Store worlds in a different directory!"
This can work, admittedly. Still, it requires twice the hard drive space.
Here's the thing. A basic warning message would take five minutes to implement, and a "good" system would take about an hour. Given how much grief accidental downgrading has caused (just count the "I lost all my items" threads in the past few months), Mojang should just implement a quick fix, even if none of the mishaps are technically their fault.
v
As I said before, just ignoring the issue and blaming the player won't solve the underlying issue, because people not making backups is not the cause of their worlds getting corrupted due to their inattentiveness. Rather, it's because it was possible at all. Thus, the solution becomes not blaming the end user, but making it so loading a world in an older version is impossible to do on accident. (But please, allow it to be done on purpose so we can purposefully corrupt our worlds for enjoyment to see what may happen!)
Some times people have to do that though. My survival world is 14w31a currently and I always use that version for my worlds, but some times I need to use 1.7.10 to play on a server I run with my friend. More than once I just completely forgot to change the game profile in the launcher after playing on the server and often didn't remember until I was already loading the world or saw my empty inventory. The Game Directory thing in the launcher is one solution that I have since taken advantage of, but it is not a very intuitive one for the casual everyday user. Of course it is on my hands to get brain-farts, but is it unreasonable of me as a user to expect the software to handle this very possible scenario gracefully so that I don't have to exit the game and restore the backup?
The key principle of usability is that the user shouldn't have to think or be concerned with software quirks. To make another example, suppose Mojang never added a horizontal collision system to the game, would it be their responsibility to add the collision system or would it be the user's responsibility to be aware of this limitation and actively not walk through the walls? It is an extreme analogy of course but does bring home my point. I am a software developer myself and I personally think developers should do as much as they can within reason to protect users from themselves and their brain-farts and limited technical skills. This specific case is a very reasonable and quick one to address and by now could have saved god knows how many worlds from oblivion, the benefit is obvious.