blender
/
blender
133
398
Fork 579
Code Issues 6.3k Pull Requests 747 Projects 19 Wiki Activity

How to Handle Forward Compatibility #109151

New Issue
Closed
opened 2023-06-20 10:51:28 +02:00 by Bastien Montagne · 18 comments
Bastien Montagne commented 2023-06-20 10:51:28 +02:00
Owner
Copy Link

Forward compatibility is the ability of a software to open files generated by a more recent version of itself.

Blender has been designed since the beginning with a strong forward compatibility capacity. Its low-level data model (DNA) and its file format intrinsically support it.

On a higher level (user-level data and features) however, it is much more challenging to achieve over a long period of time. This is especially true when existing type of data or features are refactored.

Two types of forward compatibility breakage can be identified:

  1. New feature or data type: This is the common, expected breaking case. An older version of Blender is not expected to understand and use data or feature that did not exist back then.
  2. Refactor of existing feature or data type. There are two sub-cases here:
    A. Refactor 'in place', where the internal organization and meaning of the data changes, but the general container (often an ID) remain the same. E.g. recently, the refactor of the Mesh data-block.
    B. Refactor by replacing a deprecated data by a new one. E.g. recently the replacement of Proxies by LibOverrides, or the future replacement of Greasepencil v2 by the v3.
    From a forward compatibility perspective, the A variant is usually way more difficult to handle properly than the B one.

Current Situation

So far, Blender has striven to ensure as much forward compatibility as possible, following these principles:

  • A .blend file should always open in any older Blender version.
  • Type 1 of breakages described above are expected and normal, they happen all the time.
    • Older versions of Blender simply ignore these new features and data types.
    • These new features and data types are lost if the .blend file is saved with the older version of Blender.
    • There is no warning about it.
  • Type 2 of breakages are kept as rare as possible.
    • They are only allowed when switching to a new major release.
    • They involve a change in the BLENDER_FILE_MIN_VERSION/BLENDER_FILE_MIN_SUBVERSION.
    • The file should still open in older versions of Blender, but there may be massive loss of data.
    • There is a warning when opening such 'too new' .blend files.

Problems With Current Situation

While current situation works OK most of the time in basic cases (like appending a mesh object from a more recent .blend file version), it is usually impossible/unusable to open e.g. complex production files with older Blender versions.

Further more, the lack of documentation and testing has lead to critical breakages recently. E.g. any .blend file saved with Blender 4.0 containing a mesh will crash on any version version of Blender 3.5 or older. This includes the 3.3 LTS one (see #108491).

Proposed New Handling

Note: here, when referring to a .blend file, "incompatible" means that its min version > current Blender version, and "newer" means that its version > current Blender version.

The main proposed change is to not allow opening .blend files when their BLENDER_FILE_MIN_VERSION is higher than the current blender version.

This would integrate into this new proposed handling:

  • A .blend file can only be open in older Blender versions within the same major release cycle, and the latest LTS from the previous major release cycle.
    • E.g. a .blend file from Blender 4.1 would be loadable by Blender 3.6 LTS, and Blender 4.0.
    • The same should be true when linking or appending data.
  • Type 1 of breakages described above are expected and normal, they happen all the time.
    • Older versions of Blender simply ignore these new features and data types.
    • These new features and data types are lost if the .blend file is saved with the older version of Blender.
    • There should be warning about it:
      • Have a permanent warning somewhere in the UI (footer?), instead of the popup only visible when opening.
      • Have a warning when saving a newer .blend file with an older version of Blender.
      • Later only warning when actual data loss is expected could be investigated. However, achieving a reliable detection of such cases will likely be very difficult.
  • Type 2 of breakages are kept as rare as possible.
    • They are only allowed when switching to a new major release (so roughly every two years).
    • They involve a change in the BLENDER_FILE_MIN_VERSION/BLENDER_FILE_MIN_SUBVERSION.
    • When trying to open such files in older, incompatible versions of Blender, user should get a message stating the minimum Blender version expected to be able to open the file.
    • Depending on the affected data and feature, the latest LTS version of the previous major release cycle can be kept compatible with both major versions, having a role of 'converter' to the older version of the data (e.g. Blender 3.6 can open meshes from 4.0, and will save them in the older 3.x compatible format).
  • Some automated testing for backward and forward compatibility should be created.
  • The expected handling regarding compatibility needs to be documented on the wiki.

Proposed Practical Changes

In case new handling described above is accepted, here are the proposed steps to implement it, by order of highest priority:

  • Prevent older blender versions to open incompatible .blend files, to be done in main, and backported to 3.6 and 3.3 LTS's.
    • Include info message saying which minimal version of Blender to use to open the file.
  • Lower the minfile version in main to 3.6 (to allow 3.6 to be used as converter between both mesh data versions).
  • Implement more systematic warning about data loss when a newer .blend file is open, and when trying to save it.
    • image
    • image
  • Add some automated testing (CI) for forward (and backward!) compatibility. Created dedicated task: #110922
  • Document the new version handling process in the wiki.
  • Add summary of this policy to the user manual (blender/blender-manual#104522).
  • Backport code changes to 3.6LTS (!110568).
  • Backport code changes to 3.3LTS (!110574).
  • Add an Interest/Compatibility label to projects.blender.org
Forward compatibility is the ability of a software to open files generated by a more recent version of itself. Blender has been designed since the beginning with a strong forward compatibility capacity. Its low-level data model (DNA) and its file format intrinsically support it. On a higher level (user-level data and features) however, it is much more challenging to achieve over a long period of time. This is especially true when existing type of data or features are refactored. Two types of forward compatibility breakage can be identified: 1. New feature or data type: This is the common, expected breaking case. An older version of Blender is not expected to understand and use data or feature that did not exist back then. 2. Refactor of existing feature or data type. There are two sub-cases here: A. Refactor 'in place', where the internal organization and meaning of the data changes, but the general container (often an ID) remain the same. E.g. recently, the refactor of the Mesh data-block. B. Refactor by replacing a deprecated data by a new one. E.g. recently the replacement of Proxies by LibOverrides, or the future replacement of Greasepencil v2 by the v3. From a forward compatibility perspective, the `A` variant is usually way more difficult to handle properly than the `B` one. ## Current Situation So far, Blender has striven to ensure as much forward compatibility as possible, following these principles: * A .blend file should always open in any older Blender version. * Type 1 of breakages described above are expected and normal, they happen all the time. * Older versions of Blender simply ignore these new features and data types. * These new features and data types are lost if the .blend file is saved with the older version of Blender. * There is no warning about it. * Type 2 of breakages are kept as rare as possible. * They are only allowed when switching to a new major release. * They involve a change in the `BLENDER_FILE_MIN_VERSION`/`BLENDER_FILE_MIN_SUBVERSION`. * The file should still open in older versions of Blender, but there may be massive loss of data. * There is a warning when opening such 'too new' .blend files. ## Problems With Current Situation While current situation works OK most of the time in basic cases (like appending a mesh object from a more recent .blend file version), it is usually impossible/unusable to open e.g. complex production files with older Blender versions. Further more, the lack of documentation and testing has lead to critical breakages recently. E.g. any .blend file saved with Blender 4.0 containing a mesh will crash on any version version of Blender 3.5 or older. This includes the 3.3 LTS one (see #108491). ## Proposed New Handling Note: here, when referring to a .blend file, "incompatible" means that its min version > current Blender version, and "newer" means that its version > current Blender version. The main proposed change is to not allow opening .blend files when their `BLENDER_FILE_MIN_VERSION` is higher than the current blender version. This would integrate into this new proposed handling: * A .blend file can only be open in older Blender versions within the same major release cycle, and the latest LTS from the previous major release cycle. * E.g. a .blend file from Blender 4.1 would be loadable by Blender 3.6 LTS, and Blender 4.0. * The same should be true when linking or appending data. * Type 1 of breakages described above are expected and normal, they happen all the time. * Older versions of Blender simply ignore these new features and data types. * These new features and data types are lost if the .blend file is saved with the older version of Blender. * There should be warning about it: * Have a permanent warning somewhere in the UI (footer?), instead of the popup only visible when opening. * Have a warning when saving a newer .blend file with an older version of Blender. * Later only warning when actual data loss is expected could be investigated. However, achieving a reliable detection of such cases will likely be very difficult. * Type 2 of breakages are kept as rare as possible. * They are only allowed when switching to a new major release (so roughly every two years). * They involve a change in the `BLENDER_FILE_MIN_VERSION`/`BLENDER_FILE_MIN_SUBVERSION`. * When trying to open such files in older, incompatible versions of Blender, user should get a message stating the minimum Blender version expected to be able to open the file. * Depending on the affected data and feature, the latest LTS version of the previous major release cycle can be kept compatible with both major versions, having a role of 'converter' to the older version of the data (e.g. Blender 3.6 can open meshes from 4.0, and will save them in the older 3.x compatible format). * Some automated testing for backward and forward compatibility should be created. * The expected handling regarding compatibility needs to be documented on the wiki. ## Proposed Practical Changes In case new handling described above is accepted, here are the proposed steps to implement it, by order of highest priority: - [x] Prevent older blender versions to open incompatible .blend files, to be done in main, and backported to 3.6 and 3.3 LTS's. - [x] Include info message saying which minimal version of Blender to use to open the file. - [x] Lower the minfile version in main to `3.6` (to allow 3.6 to be used as converter between both mesh data versions). - [x] Implement more systematic warning about data loss when a newer .blend file is open, and when trying to save it. - ![image](/attachments/d6994a7d-7c3b-443d-a464-0a94d87b36f7) - ![image](/attachments/f0f8f3c9-3be5-4d79-b162-9a15814b6f08) - [x] ~~Add some automated testing (CI) for forward (and backward!) compatibility.~~ Created dedicated task: #110922 - [x] [Document the new version handling process](https://wiki.blender.org/wiki/Process/Compatibility_Handling) in the wiki. - [x] Add summary of this policy to the user manual (https://projects.blender.org/blender/blender-manual/pulls/104522). - [x] Backport code changes to 3.6LTS (!110568). - [x] Backport code changes to 3.3LTS (!110574). - [x] Add an `Interest/Compatibility` label to projects.blender.org
image.png
56 KiB
👍 4 🚀 1
Bastien Montagne added the
Interest
BlendFile
Type
Design
Module
Core
 labels 2023-06-20 10:51:29 +02:00
Bastien Montagne commented 2023-06-20 13:11:22 +02:00
Author
Owner
Copy Link

@brecht @sergey @dfelinto @Ton here is the design task for the forward compatibility issue. Let me know if I forgot something or am not clear enough.

@ideasman42 think this topic may also interest you?

@brecht @sergey @dfelinto @Ton here is the design task for the forward compatibility issue. Let me know if I forgot something or am not clear enough. @ideasman42 think this topic may also interest you?
Dalai Felinto commented 2023-06-20 15:08:03 +02:00
Owner
Copy Link

Implement more systematic warning about data loss when opening a newer blendfile and/or trying to save it.

My proposal is:

  • No warnings on file open (or link/append) - there is no data loss in this case.
  • Permanent warning on the status bar (see mockups).
  • Warning on saving (incorporated to the "Save" dialog).

Eventually we could be smarter about when to show the version warning (e.g., only when Blender read non-UI DNA data that was discarded).

Mockup of how the status bar could look like when we have a version forward-mismatch. When there is no warning, we can show the status bar with "plain-text" as we do now e.g., 3.5).

image

Detailed view + mouse to get more information:

image

It can still be combined with more information.

image

> Implement more systematic warning about data loss when opening a newer blendfile and/or trying to save it. My proposal is: * No warnings on file open (or link/append) - there is no data loss in this case. * Permanent warning on the status bar (see mockups). * Warning on saving (incorporated to the "Save" dialog). Eventually we could be smarter about when to show the version warning (e.g., only when Blender read non-UI DNA data that was discarded). --- Mockup of how the status bar could look like when we have a version forward-mismatch. When there is no warning, we can show the status bar with "plain-text" as we do now e.g., 3.5). ![image](/attachments/55da4a44-dc67-467f-a0c7-90e4435a7ed9) ---- Detailed view + mouse to get more information: ![image](/attachments/d6994a7d-7c3b-443d-a464-0a94d87b36f7) It can still be combined with more information. ![image](/attachments/45ef3417-35dc-4c89-8930-687a4575f413)
image.png
574 KiB
image.png
53 KiB
image.png
56 KiB
👍 4
Pablo Vazquez commented 2023-06-20 15:31:25 +02:00
Member
Copy Link

My proposal is:

  • No warnings on file open (or link/append) - there is no data loss in this case.

+1 (although you probably mean no popup or report warning, since there will be an indicator in the status bar)

  • Permanent warning on the status bar (see mockups).

+1
Completely offtopic but this compact layout is great for when we have Blender updates checker (in green, not red)

  • Warning on saving (incorporated to the "Save" dialog).

+1, this is the most important one because this is when you could lose data.

On Save/Ctrl+S, instead of simply saving, Blender should open the blocking dialog similar to when we have modified images:
image

With the text This file has been saved with a newer version of Blender (4.0.0), it is recommended to use that version (or newer) to prevent loss of data., or something along those lines.

> My proposal is: > * No warnings on file open (or link/append) - there is no data loss in this case. +1 (although you probably mean no *popup* or report warning, since there will be an indicator in the status bar) > * Permanent warning on the status bar (see mockups). +1 Completely offtopic but this compact layout is great for when we have Blender updates checker (in green, not red) > * Warning on saving (incorporated to the "Save" dialog). +1, this is the most important one because this is when you could lose data. On Save/Ctrl+S, instead of simply saving, Blender should open the blocking dialog similar to when we have modified images: ![image](/attachments/8587017d-a8b1-4c86-938a-05381f7cc72b) With the text `This file has been saved with a newer version of Blender (4.0.0), it is recommended to use that version (or newer) to prevent loss of data.`, or something along those lines.
image.png
56 KiB
Brecht Van Lommel commented 2023-06-21 19:42:25 +02:00
Owner
Copy Link

This seems generally fine.

Am I understanding correctly that we are not planning any changes for 3.6.0 then?

  • A .blend file can only be open in older Blender versions within the same major release cycle, and the latest LTS from the previous major release cycle.
    • Handling of linking/appending here is unclear. Should it still be allowed?

In my opinion, no. The set of problems we are trying to prevent is the same as opening the .blend file.

  • Prevent older blender versions to open incompatible blendfiles, to be done in main, and backported to 3.6 and 3.3 LTS's.
  • Implement more systematic warning about data loss when opening a newer blendfile and/or trying to save it.

To be clear, "incompatible" here means the .blend file min version > current Blender version, and "newer" means .blend file version > current Blender version.

This seems generally fine. Am I understanding correctly that we are not planning any changes for 3.6.0 then? > * A .blend file can only be open in older Blender versions within the same major release cycle, and the latest LTS from the previous major release cycle. > * Handling of linking/appending here is unclear. Should it still be allowed? In my opinion, no. The set of problems we are trying to prevent is the same as opening the .blend file. > - [ ] Prevent older blender versions to open incompatible blendfiles, to be done in main, and backported to 3.6 and 3.3 LTS's. > - [ ] Implement more systematic warning about data loss when opening a newer blendfile and/or trying to save it. To be clear, "incompatible" here means the .blend file min version > current Blender version, and "newer" means .blend file version > current Blender version.
Bastien Montagne commented 2023-06-21 20:39:58 +02:00
Author
Owner
Copy Link

This seems generally fine.

Am I understanding correctly that we are not planning any changes for 3.6.0 then?

I think there will be changes (need to backport the 'do not open too much future files' process in there as well), but I don't think there is anything urgent, it can be done as part of a future 3.6LTS update imho.

  • A .blend file can only be open in older Blender versions within the same major release cycle, and the latest LTS from the previous major release cycle.
    • Handling of linking/appending here is unclear. Should it still be allowed?

In my opinion, no. The set of problems we are trying to prevent is the same as opening the .blend file.

Agreed.

  • Prevent older blender versions to open incompatible blendfiles, to be done in main, and backported to 3.6 and 3.3 LTS's.
  • Implement more systematic warning about data loss when opening a newer blendfile and/or trying to save it.

To be clear, "incompatible" here means the .blend file min version > current Blender version, and "newer" means .blend file version > current Blender version.

Yes, correct.

> This seems generally fine. > > Am I understanding correctly that we are not planning any changes for 3.6.0 then? I think there will be changes (need to backport the 'do not open too much future files' process in there as well), but I don't think there is anything urgent, it can be done as part of a future 3.6LTS update imho. > > * A .blend file can only be open in older Blender versions within the same major release cycle, and the latest LTS from the previous major release cycle. > > * Handling of linking/appending here is unclear. Should it still be allowed? > > In my opinion, no. The set of problems we are trying to prevent is the same as opening the .blend file. Agreed. > > - [ ] Prevent older blender versions to open incompatible blendfiles, to be done in main, and backported to 3.6 and 3.3 LTS's. > > - [ ] Implement more systematic warning about data loss when opening a newer blendfile and/or trying to save it. > > To be clear, "incompatible" here means the .blend file min version > current Blender version, and "newer" means .blend file version > current Blender version. Yes, correct.
Bastien Montagne commented 2023-06-21 20:52:21 +02:00
Author
Owner
Copy Link

Thanks for the feedback, updated the design task accordingly (regarding warnings when opening newer .blend file, and no support for link/append from incompatible .blend file).

Thanks for the feedback, updated the design task accordingly (regarding warnings when opening newer .blend file, and no support for link/append from incompatible .blend file).
Campbell Barton commented 2023-06-22 06:04:38 +02:00
Owner
Copy Link

Proposal looks good, am not so keen on permanent warning (adds a special case & needs to coexist with other warnings which come & go while using Blender), but I don't feel that strongly about it either.

Proposal looks good, am not so keen on permanent warning (adds a special case & needs to coexist with other warnings which come & go while using Blender), but I don't feel that strongly about it either.
Dalai Felinto commented 2023-06-23 14:12:19 +02:00
Owner
Copy Link

A mockup on top of what Pablo suggested. I added the Save As option, but also made the text a bit shorter.

image

Override file with an older Blender version?

This file has been saved with a newer version of Blender (4.0). 
Saving with current Blender (3.6) may lead to loss of data.

I would suggest going with this and do a final pass on the text after the 3.6 release once Pablo has more time.

Edit: Overwrite may be the correct English term, and we could even use that instead of "Save" in the button label.

A mockup on top of what Pablo suggested. I added the Save As option, but also made the text a bit shorter. ![image](/attachments/d7d947e4-a8d8-4e3e-89de-84b8e91b46e9) ``` Override file with an older Blender version? This file has been saved with a newer version of Blender (4.0). Saving with current Blender (3.6) may lead to loss of data. ``` I would suggest going with this and do a final pass on the text after the 3.6 release once Pablo has more time. Edit: Overwrite may be the correct English term, and we could even use that instead of "Save" in the button label.
image.png
56 KiB
👍 5
Falk David commented 2023-06-25 11:55:44 +02:00
Member
Copy Link

@dfelinto Since this dialog looks very close to the "Do you want to save before closing blender?" dialog, I suggest to change the icon to the warning symbol. On top of having the button say "Overwrite".

And another question: What about the autosave? Should that just save the current state as-is?

@dfelinto Since this dialog looks very close to the "Do you want to save before closing blender?" dialog, I suggest to change the icon to the warning symbol. On top of having the button say "Overwrite". And another question: What about the autosave? Should that just save the current state as-is?
👍 2
Dalai Felinto commented 2023-06-26 11:57:49 +02:00
Owner
Copy Link

@filedescriptor Auto Save doesn't overwrite existing data, it creates new files in the temp directory. It should just keep saving what it already does. So users can recover from a crash and still decide whether they want to save the changes, save as, or export to another format.

Since this dialog looks very close to the "Do you want to save before closing blender?" dialog, I suggest to change the icon to the warning symbol.

I have no strong opinion here and I'm ok deferring to Pablo to make a decision. But I find both scenarios equally alarming, so not sure I would priorizite one with exclamation mark over the other.

@filedescriptor Auto Save doesn't overwrite existing data, it creates new files in the temp directory. It should just keep saving what it already does. So users can recover from a crash and still decide whether they want to save the changes, save as, or export to another format. > Since this dialog looks very close to the "Do you want to save before closing blender?" dialog, I suggest to change the icon to the warning symbol. I have no strong opinion here and I'm ok deferring to Pablo to make a decision. But I find both scenarios equally alarming, so not sure I would priorizite one with exclamation mark over the other.
Andres Stephens commented 2023-06-26 19:58:31 +02:00
Contributor
Copy Link

Per the request for feedback from the weeklies on devatalk: I am pro the UX of adding more warnings, either permenant with versioning warnings on overwrite or save as. Good proposal and solution to the issue.

Per the request for feedback from the weeklies on devatalk: I am pro the UX of adding more warnings, either permenant with versioning warnings on overwrite or save as. Good proposal and solution to the issue.
Bastien Montagne commented 2023-06-30 16:55:42 +02:00
Author
Owner
Copy Link

Added a WIP wiki page about Blender compatibility handling: https://wiki.blender.org/wiki/Process/Compatibility_Handling

Also had to add a section about backward compatibility, though this is a more straight-forward topic I think it's good to be documented as well.

Still very much WIP, though.

Added a WIP wiki page about Blender compatibility handling: https://wiki.blender.org/wiki/Process/Compatibility_Handling Also had to add a section about backward compatibility, though this is a more straight-forward topic I think it's good to be documented as well. Still very much WIP, though.
👍 1
Adi.Sage commented 2023-07-05 19:11:50 +02:00
Contributor
Copy Link

This looks great guys, and a very much needed feature!
If I may add my two cents based on my personal experience (coming from India where English is non-native)

Override file with an older Blender version?

This file has been saved with a newer version of Blender (4.0).
Saving with current Blender (3.6) may lead to loss of data.

  • Artists are not very receptive of long, wordy messages. It will be great if we can use a shorter but precise message.

Since this dialog looks very close to the "Do you want to save before closing blender?" dialog, I suggest to change the icon to the warning symbol. On top of having the button say "Overwrite".

  • I agree with @filedescriptor. Responding to dialog boxes becomes a part of muscle memory and no one really reads the actual message every time. A slight change in color/symbol will be much appreciated.
    For the same reason, I would also suggest the default option should be Save As, and the alternative should be Save/Overwrite.

But I find both scenarios equally alarming,

  • @dfelinto agreed, but this scenario will be rarer and more destructive, hence requires more discretion IMO.

Mockup based on suggestions (looks messy because I'm throwing in all ideas... we can pick only what works for us) :

version check.jpg

This looks great guys, and a very much needed feature! If I may add my two cents based on my personal experience (coming from India where English is non-native) > Override file with an older Blender version? > > This file has been saved with a newer version of Blender (4.0). > Saving with current Blender (3.6) may lead to loss of data. - Artists are not very receptive of long, wordy messages. It will be great if we can use a shorter but precise message. ----------------------------- > Since this dialog looks very close to the "Do you want to save before closing blender?" dialog, I suggest to change the icon to the warning symbol. On top of having the button say "Overwrite". - I agree with @filedescriptor. Responding to dialog boxes becomes a part of muscle memory and no one really reads the actual message every time. A slight change in color/symbol will be much appreciated. For the same reason, I would also suggest the default option should be Save As, and the alternative should be Save/Overwrite. ----------------------------- > But I find both scenarios equally alarming, - @dfelinto agreed, but this scenario will be rarer and more destructive, hence requires more discretion IMO. ----------------------------- Mockup based on suggestions (looks messy because I'm throwing in all ideas... we can pick only what works for us) : ![version check.jpg](/attachments/c2a36925-9ec1-4d0a-b5cb-521e8b7cb2a9)
version check.jpg
63 KiB
👍 3
Sybren A. Stüvel commented 2023-07-17 11:21:22 +02:00
Member
Copy Link

To be clear, "incompatible" here means the .blend file min version > current Blender version, and "newer" means .blend file version > current Blender version.

For extra clarity, I'd replace "current Blender" with "currently running Blender". I had to read a few times before I understood this, as "current Blender version" could also be read as "the latest release".

Mockup based on suggestions (looks messy because I'm throwing in all ideas... we can pick only what works for us) :

version check.jpg

I think the "will be converted" is too promising. This mockup starts with a positive message that your data will be converted. The warning that this might not be a complete conversion is only shown at the end, and in the smallest font. I'd be afraid people are going to miss it.

I do like the red "Overwrite" button on the right, and the blue "Save As" button on the left. This makes the non-overwriting, safe option the default, and the dangerous, lossy option the special one. If people don't read and just click the right-most button (as that's typically the "next next next until it's done" spot) they don't lose their data.

> To be clear, "incompatible" here means the .blend file min version > current Blender version, and "newer" means .blend file version > current Blender version. For extra clarity, I'd replace "current Blender" with "currently running Blender". I had to read a few times before I understood this, as "current Blender version" could also be read as "the latest release". > Mockup based on suggestions (looks messy because I'm throwing in all ideas... we can pick only what works for us) : > > ![version check.jpg](/attachments/c2a36925-9ec1-4d0a-b5cb-521e8b7cb2a9) I think the "will be converted" is too promising. This mockup starts with a positive message that your data will be converted. The warning that this might not be a complete conversion is only shown at the end, and in the smallest font. I'd be afraid people are going to miss it. I do like the red "Overwrite" button on the right, and the blue "Save As" button on the left. This makes the non-overwriting, safe option the default, and the dangerous, lossy option the special one. If people don't read and just click the right-most button (as that's typically the "next next next until it's done" spot) they don't lose their data.
Brecht Van Lommel commented 2023-07-20 13:41:40 +02:00
Owner
Copy Link

Note that there is now an actual implementation in #110109 to test and give UI feedback on.

Note that there is now an actual implementation in #110109 to test and give UI feedback on.
Julian Eisel commented 2023-07-25 19:19:37 +02:00
Member
Copy Link

There should also be user level documentation making it clear what users can expect regarding file compatibility. On a quick search I couldn't find anything in the current manual.

There should also be user level documentation making it clear what users can expect regarding file compatibility. On a quick search I couldn't find anything in the current manual.
❤️ 1
Bastien Montagne commented 2023-07-26 10:58:06 +02:00
Author
Owner
Copy Link

There should also be user level documentation making it clear what users can expect regarding file compatibility. On a quick search I couldn't find anything in the current manual.

Good point, added another entry to the TODO list in the task above.

> There should also be user level documentation making it clear what users can expect regarding file compatibility. On a quick search I couldn't find anything in the current manual. Good point, added another entry to the TODO list in the task above.
Bastien Montagne commented 2023-08-10 11:37:04 +02:00
Author
Owner
Copy Link

Think we can close this one now, testing compatibility has its own dedicated task: #110922.

Think we can close this one now, testing compatibility has its own dedicated task: #110922.
Blender Bot added the
Status
Archived
 label 2023-08-10 11:37:10 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
brush-assets-project
universal-scene-description
fix-121021
blender-v4.1-release
blender-v3.3-release
blender-v3.6-release
blender-v3.6-temp_wmoss_animrig_public
temp-sculpt-dyntopo
gpencil-next
anim/animation-id-113594
blender-v4.0-release
blender-projects-basics
bridge-curves
sculpt-blender
asset-browser-frontend-split
asset-shelf
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-v2.93-release
realtime-clock
sculpt-dev
bevelv2
xr-dev
v4.1.1
v3.6.11
v3.3.18
v4.1.0
v3.3.17
v3.6.10
v3.6.9
v3.3.16
v3.6.8
v3.6.7
v3.3.14
v4.0.2
v4.0.1
v4.0.0
v3.6.5
v3.3.12
v3.6.4
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
10 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#109151
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?