infrastructure/extensions-website
4
8
Fork 10
Code Issues 20 Pull Requests 2 Projects Releases Wiki Activity

blender_version_max changes #183

New Issue
Closed
opened 2024-06-13 11:50:57 +02:00 by Dalai Felinto · 8 comments
Dalai Felinto commented 2024-06-13 11:50:57 +02:00
Owner
Copy Link

Right now users will end up doing things like blender_version_max = 4.2.9999999999. Instead the blender_version_max should indicate the first version where the extension is no longer supported.

The proposal is to rename it to blender_version_unsupported_since and to treat it as exclusive.

  • Update documentation.
  • Update logic in Blender.
  • Update logic on server.
  • Update front-end on how this is communicated
    • Make sure the range is clear.
    • Make sure the "report bad range" is sound.
    • Make sure it is well communicated when the users change this from the Version detail page.
Right now users will end up doing things like `blender_version_max = 4.2.9999999999`. Instead the `blender_version_max` should indicate the first version where the extension is no longer supported. ~~The proposal is to rename it to `blender_version_unsupported_since` and to treat it as exclusive.~~ - [x] Update documentation. - [x] https://projects.blender.org/blender/blender-manual/pulls/104826 - [x] Updated technical docs too. - [ ] Update logic in Blender. - [x] Update logic on server. - [x] Update front-end on how this is communicated - [x] Make sure the range is clear. - [x] Make sure the "report bad range" is sound. - [x] Make sure it is well communicated when the users change this from the Version detail page.
Dalai Felinto added the
Type
Enhancement
Priority
Normal
 labels 2024-06-13 11:50:57 +02:00
Dalai Felinto commented 2024-06-13 16:46:16 +02:00
Author
Owner
Copy Link

For the front-end:

  • The "Report" message is fine as it is.
  • The range displayed could follow similar logic as what we do now (but updated for exclusion):
    • e.g., if min is "4.2.0", and max is "4.3.0", it shows "4.2"
  • Version edit is super broken ... anything is better than this:

image

For the front-end: * The "Report" message is fine as it is. * The range displayed could follow similar logic as what we do now (but updated for exclusion): - e.g., if min is "4.2.0", and max is "4.3.0", it shows "4.2" * Version edit is super broken ... anything is better than this: ![image](/attachments/e0288778-6936-4819-b7ef-623d81a7e17e)
image.png
5.0 KiB
👍 1
Dalai Felinto changed title from blender_version_max should be non-inclusive to blender_version_max changes 2024-06-13 17:39:16 +02:00
Márton Lente commented 2024-06-14 11:55:36 +02:00
Owner
Copy Link

I added some normalization to the compatibility display, which I think improves clarity if we keep displaying the supported version range in a row:

blender-version-max-changes-ui-2.png

blender-version-max-changes-ui-1.png

Alternatively, with some adjustments we could separate min. and max. versions' displays. This could also work, but most of the time Max. Blender Version would just show Latest:

blender-version-max-changes-ui-3.png

Alternatively we could make version text inputs less wide, if we change field placehorders from max. Blender version to e.g. x.x.x, as the SemVer format should be self-explanatory.

I added some normalization to the compatibility display, which I think improves clarity if we keep displaying the supported version range in a row: ![blender-version-max-changes-ui-2.png](/attachments/c8bca5e8-d830-4b0f-b29a-bad46b3a6294) ![blender-version-max-changes-ui-1.png](/attachments/b68e2c2b-7ef1-4259-8f91-c3eebc49e723) Alternatively, with some adjustments we could separate min. and max. versions' displays. This could also work, but most of the time _Max. Blender Version_ would just show _Latest_: ![blender-version-max-changes-ui-3.png](/attachments/154dd287-99ce-4259-81da-675c89b968b7) Alternatively we could make version text inputs less wide, if we change field placehorders from _max. Blender version_ to e.g. _x.x.x_, as the SemVer format should be self-explanatory.
blender-version-max-changes-ui-2.png
6.0 KiB
blender-version-max-changes-ui-3.png
14 KiB
blender-version-max-changes-ui-1.png
12 KiB
Dalai Felinto commented 2024-06-14 16:40:55 +02:00
Author
Owner
Copy Link

@martonlente

Alternatively, with some adjustments we could separate min. and max. versions' displays. This could also work, but most of the time Max. Blender Version would just show Latest:

I think this works better, no? Specially with the exclusive behaviour I think the dash is misleading.

And just to re-iterate on the feedback I shared IRL:

  • Add information about the max being exclusive. (e.g., "This is a Blender version that the extension does not support, earlier versions are supported."
  • Account for the exclusive behaviour on the range (if min is 4.2.0 and max is 4.3.0, the range should show: "4.2").
@martonlente > Alternatively, with some adjustments we could separate min. and max. versions' displays. This could also work, but most of the time Max. Blender Version would just show Latest: I think this works better, no? Specially with the exclusive behaviour I think the dash is misleading. And just to re-iterate on the feedback I shared IRL: * Add information about the max being exclusive. (e.g., "This is a Blender version that the extension does not support, earlier versions are supported." * Account for the exclusive behaviour on the range (if min is 4.2.0 and max is 4.3.0, the range should show: "4.2").
👍 1
Márton Lente commented 2024-06-14 18:48:17 +02:00
Owner
Copy Link

@dfelinto thanks for the feedback.

  • The min. and max. versions' display has been separated at all occurences.
  • The instruction text has been changed to make max version's exclusivity more clear. See below:

blender-version-max-changes-ui-4.png

*Update: Based on discussion IRL we only keep min. and max. versions' separation on edit pages (TODO). Similarily, version display conversion should only be implemented on end-user facing pages.

@dfelinto thanks for the feedback. - The min. and max. versions' display has been separated at all occurences. - The instruction text has been changed to make max version's exclusivity more clear. See below: ![blender-version-max-changes-ui-4.png](/attachments/91201ba6-fa11-4078-9b4b-63774c05cbb8) *Update: Based on discussion IRL we only keep min. and max. versions' separation on edit pages (TODO). Similarily, version display conversion should only be implemented on end-user facing pages.
blender-version-max-changes-ui-4.png
24 KiB
Márton Lente commented 2024-06-17 12:15:20 +02:00
Owner
Copy Link

The min. and max. versions' separate display has been updated, and now is exclusive to edit pages.

Thinking about the details, displaying the max. supported version to end-users (converting first unsupported semantic version to last supported version) poses some questions though:

  • Blender semantic version numbers don't always follow the same pattern when a version is bumped. This means that programmatically bumping down a version number would sometimes result in referencing non-existent versions.
  • We can set up rules how minor and patch versions get converted to previous versions (e.g. by bumping minor version only if a patch version is 0 etc.). However, this should follow a pattern that matches how extensions could potentially break by version changes.
  • I think it's only possible to make sure we never reference a non-existing version is to provide a list of historical versions e.g. in form of an array. However it'd need maintenance (unless we can fetch this data from somewhere).

Do you think defining a conversion logic that always is correct is possible based on the above?

I also wonder whether it's ok to handle this conversion on the front-end? This seems handy, but would require JavaScript to be enabled to show the correct versions.

The min. and max. versions' separate display has been updated, and now is exclusive to edit pages. Thinking about the details, displaying the max. supported version to end-users (converting first unsupported semantic version to last supported version) poses some questions though: - Blender semantic version numbers don't always follow the same pattern when a version is bumped. This means that programmatically bumping down a version number would sometimes result in referencing non-existent versions. - We can set up rules how minor and patch versions get converted to previous versions (e.g. by bumping minor version only if a patch version is `0` etc.). However, this should follow a pattern that matches how extensions could potentially break by version changes. - I think it's only possible to make sure we never reference a non-existing version is to provide a list of historical versions e.g. in form of an array. However it'd need maintenance (unless we can fetch this data from somewhere). Do you think defining a conversion logic that always is correct is possible based on the above? I also wonder whether it's ok to handle this conversion on the front-end? This seems handy, but would require JavaScript to be enabled to show the correct versions.
Oleg-Komarov commented 2024-06-20 12:19:17 +02:00
Owner
Copy Link

I have added the validation, but the form doesn't display the control and error message properly, @martonlente could you please take a look:

I have added the validation, but the form doesn't display the control and error message properly, @martonlente could you please take a look:
Screencast from 2024-06-20 12-18-03.mp4
190 KiB
👍 1
Márton Lente commented 2024-06-20 12:52:48 +02:00
Owner
Copy Link

@Oleg-Komarov thanks for adding validation!

I normalized the error message's display: should be ok now.

@Oleg-Komarov thanks for adding validation! I normalized the error message's display: should be ok now.
🚀 1
Oleg-Komarov commented 2024-07-19 18:15:31 +02:00
Owner
Copy Link

Should the issue be closed or is there still something to finish? (just keeping the tracker organized)

Should the issue be closed or is there still something to finish? (just keeping the tracker organized)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Normal
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

  
Type
Breaking
Breaking change that won't be backward compatible

  
Type
Documentation
Documentation changes

  
Type
Enhancement
Improve existing functionality

  
Type
Feature
New functionality

  
Type
Report
Something is not working

  
Type
Security
This is security issue

  
Type
Suggestion
New ideas and proposals

  
Type
Testing
Issue or pull request related to testing

No Label
Priority
Critical
Priority
High
Priority
Low
Priority
Normal
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Type
Breaking
Type
Documentation
Type
Enhancement
Type
Feature
Type
Report
Type
Security
Type
Suggestion
Type
Testing
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 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: infrastructure/extensions-website#183
No description provided.
Delete Branch "%!s()"

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?