v1.1.1 | Safer zip reader

Updates include

• Implemented context manager for zip reader, as suggested by #80 (reference)
• Re-released this v1.1.1 update from earlier in August because the source code still had v1.1.0 and thus did not actually match the github versioning. This would result in you getting a push to update to the latest version, even though this was the latest version.
  • Needed to delete the v1.1.1 release and the v1.1.1 tag, push the updated __init__.py, and re-release the tag.
  • Be sure to avoid this mistake yourself!

v1.1.0 | Pep8 + Blender 2.93-3.0 support

NOTE: This was a release that was sitting in draft for..... a long time. Publishing now beacuse it's here.

Update includes:

• Support now expanded to 2.93 and 3.0, without reducing any prior support for older blender versions. This means the addon updater now works from as low as 2.72 (to my knowledge) all the way through current alpha builds of Blender 3.0. #74
• Transformation to better follow pep8 guidelines
  • Essentially every line of code is touched by this change. Most notably, the switch from tabs to spaces, but also better following many other pythonic conventions across the board.
  • Big thanks to neomonkeus for the work. #73
• Some minor readme updates and clarifications.
• Fixing an issue where some files couldn't be overwritten by patterns #63
• Improved verbose logging with stack traces for easier debugging, thanks to #68

v1.0.8 | Updates for 2.8 and API fixes

Updates include:

• Fixed GitLab API connections by adding user agent to (all) requests #60
• Fixed the user of handlers for popups in Blender 2.8 #53
• Added functional testing framework, to quickly ensure all API calls are still functional in the future
• Better detection of ssl connection issues, and prompting the user towards manual downloads if issues arise

v1.0.6

Updated behavior and new features

• The addon now supports both Blender 2.8 and 2.7 at the same time
  • Note that, because Blender 2.8 requires setting the minimum Blender version to (2, 80, 0) or higher, users who enable this demo addon 2.7x will see a warning that the addon was made with a newer blender version. Despite this, everything should work correctly still.
• The internally used json state file will now include the addon name as part of the path [WIP: make function to rename if non-prepended name exists]
  • For backwards compatibility, no action is needed when updating to this more recent code. The updater will automatically detect updater_status.json files and rename it to the according {package_name}_updater_status.json name.
  • This change was made to make the updater more flexible in how it is used, such as when implementing an addon which might manage the updater module for multiple other addons in a central place.
• Added distinguished error message for access denied upon 403 http response (error codes were already always displayed regardless)

Bug fixes

• The run update function now actively uses the addon_root property to know when to install the updated code already downloaded. Previously it was making an assumption of the subfolder not using this property.
  • This does not affect the default configuration of the updater code.
• The "target version install" feature for GitLab was not working right, and was always installing the master branch. This was due to an issue in the API string arguments.
  • Bitbucket and GitHub were unaffected and have been functioning correctly.
• Minor fixes to handling of http errors
• Fixed name type instance of self._latest_release (subwords were reversed)
• Wrapped the ssl._create_unverified_context function call in try/catch, as some users can run into library errors with this function and is unnecessary for most users.
• Added console printouts before in more places before assigning the error to class property.
• Removed unused library imports

v1.0.5 | Condensed UI, Release support, and other fixes

If you want to test the updater, try downloading the master branch file and installing it directly (as a .zip) into blender. Already have a version of the updater addon installed? Well.. then press the 'check for update' button!

Update logs

• Added clearer error message for users encountering SSL issues; see this active issue thread (#39) and related commit (a392e5d)
• Added an alternate, more condensed draw function (08afe00), (image here)
• Made the panel update notice UI slightly more condensed as well (image here)
• The check-now operator in user preferences will automatically re-draw the panel when finished
  • Previously you might have to move the mouse around to trigger a panel re-draw to show the response of the update check
• Internally used operators are now hidden from the popup search
• Resolved bug where any repo with update-to-branches enabled but no releases (within defined compatible range) would raise an error when checking for updates (4f4810e) and (9c4a473)
• Resolved bug where repos using update-to-branches would falsely think an update is available if there was a connection error (e.g. no internet) (c3201f3)
• Made backups more robust by explicitly looking to delete the temp folder (only applicable if a previous update/backup failed to complete) (266486f)
• URL requests now generate an unverified context SSL cert, which allows the updater to work even in proxy settings (where SSL already isn't needed) (#35)
• Created more robust clear_state function and fallback handling
• Adjusted the UI for the "Update Now!" popup to explicitly have Update, Ignore, and Defer (image here)
• Added new properties for more granular control:
  • showpopups for declaring whether popup notifications will exist or not (only previous behavior was and current default is now the this set to being 'True')
  • subfolder_path for declaring the root location of the addon, to account for different git repo structures (such as the actual addon / __init__.py file being located in a subfolder of a repo)
  • use_releases is a GitHub-specific property which will use releases instead of just tags. Releases are annotated tags (tags may not necessarily be a release, but a release is always a tag), and provide more information such as links to attachments ("assets") as well as release log text such as this message. This setting is ignored in GitLab and Bitbucket setups.
  • select_link is to be assigned a function which, given a tag object, will return the desired download link. By default, it is pre-assigned the function select_link_function which acts the same as before, however sample code is provided showing how this function could be altered in order to e.g. use GitHub attachments as the source instead of the raw sourcecode, useful if there is OS-specific compiling required. Note: this option is more advanced, and really only useful on GitHub repos which use the new use_releases function set to TRUE.

Thanks to all the contributors to this release, including @schroef, @ndee85, and @ombre5733

Did you previously incorporate updating into your addon, but want to update this updater?

To best update your addon: please completely overwrite both the ops file and the updater python module, then follow this updated tutorial. This is because the name of some options have changed, thus the whole code set needs to be updated or things will break (silently). You can safely copy your back in previous settings in the register portion of the addon_updater_ops.py file from previous versions, but read above about leveraging new settings.

In the event of any problems, please open a new issue ticket.

v1.0.4 | Support for Bitbucket & Gitlab

If you want to test the updater, try downloading the master branch file and installing it directly (as a .zip) into blender.

Update logs

• Added support for Bitbucket and GitLab
  • This is a big new capability, you can now use the addon updater if you code is publicly hosted on GitHub, GitLab, or Bitbucket. Support also already exists for connecting to private GitLab repositories (see readme notes and security considerations)
  • The tutorial here has been updated with instructions on how to appropriately set the "engine"
  • Support for private Bitbucket and GitHub repositories is planned and in progress, but not yet implemented here
• Implemented rule patterns for how to process update files. Read this before updating your own updater code!!
  • Added two new properties which control how and which files get removed or overwritten during the updating process. Previously, any file found in the update.zip would overwrite a corresponding file in the local addon install. Now, you can control the behavior as appropriate to only overwrite certain files or remove files that are no longer needed.
  • Property remove_pre_update_patterns is a list of strings, including wildcards, which defines which files will be deleted prior to running the update, regardless of whether the files to be deleted are found in the update itself. Previously, the updater never deleted any files (at most would overwrite), so this could be used to clean up old files that are no longer used such if the structure of the addon changed or files were renamed. The default is set to [ ], ie an empty list.
  • Property overwrite_patterns is a list of strings, including wildcards, which defines which files will be overwritten during the update if a file name/relative location in the update matches that of a file in the current install. Anything that matches an pattern here will be overwritten, otherwise it will be left alone. The default value is set to ["*.py","*.pyc"].
  • This section of the readme file contains some good examples of different use cases of these settings
  • Default behavior now matches blender behavior for when user manually installs an updated zip file for an addon that is already installed. That is, it will overwrite all .py files, but will NOT replace any resource folders (e.g. txt, json, .blend) included in the installing zip update.
• Implemented "clean installing" (by default, not used anywhere with demo configuration)
  • When the run_update method is triggered with clean=True, it will be similar to a fresh install where the user would first delete the addon and then re-install it fresh with the new update.
  • The 3 update-triggering operators (for popups, user preferences, and target version installing) implemented in the ops file now have hidden properties called "clean_install", defaulted to false. If you want to allow a user to clean install an update/target version, thus removing any local or old files, then simply set this property to be True
  • Note that when using a clean install, it will recursively remove all folders and files in the addon's subfolder, except those in the defined updater subfolder (so it will not remove backups or the staged update about to be installed)
  • Example:

layout.operator(addon_updater_update_now.bl_idname,
				"Update now to "+str(updater.update_version),
				clean_install=True)

• Updated logs for verbose to be slightly less verbose, it will no longer print out all details of the latest release (which included urls etc), but rather just print out the name of the version received

Already implemented the addon updater - and want to update the code?

To best update your addon: please completely overwrite both the ops file and the updater python module, then follow this updated tutorial. This is because the name of some options have changed, thus the whole code set needs to be updated or things will break (silently). You can safely copy your previous settings in the register portion of the ops file from previous versions, but read above about leveraging new pattern rules.

In the event of any problems, please open a new issue ticket.

v1.0.3 | Multi branch update

This update fixed a number of items as well as includes new features

• You are now able to directly install multiple branches
  • Please note: the updater property "include_master" has been renamed to "include_branches" and now there is also a property called "include_branch_list" which is a list of the branches.
  • The first branch listed will appear first in the UI popups and related fields.
• Fixed an issue where popups would still show if the user installed the update manually and had auto-check enabled
• Improved UI line spacing for text blocks
• Adjusted UI and backend to better support use case of having no releases but still allowing user to update to master/another branch (not this doesn't do any version comparisons)

Already implemented the addon updater - and want to update the code?

To best update your addon: please completely overwrite both the ops file and the updater python module, then follow this tutorial again. This is because the name of some options have changed (e.g. no longer called include_master but rather include_branches, thus the whole code set needs to be updated or things will break (silently).

Slight update on May 6, 2017: the demo addon had the wrong version named in bl_info.

v1.0.2 | Failsafe update

Changes

This update introduces some extra failsafe code which ensures that even if an issue with the addon_updater.py module occurs, the addon will still successfully be installed. It does this by instead nullifying the rest of the module and creating a single reference to a dummy class instead. The operator code file should still always run successfully, and any references to function calls in the updater module are handled appropriate to skip.

Also added code to change printouts when checking for updates - it will now specify by name of the addon printing out the info in case multiple versions are installed.

There are no bug fixes or critical issues reported on in this version update, the change above is purely preventive to increase stability (such as due to custom modifications of the addon_updater module).

Update instructions, for existing addons using v1.0.0 or v1.0.1 code in place

In order to utilize this update from an existing addon using this code:

• Completely replace the old addon_updater.py with the new addon_updater.py
• In the addon_updater_ops.py file, your best option is to replace the old file with the new file - but don't forget to add in the local setting changes, such as defining the name of your addon at the start of the module (now line 44) and any of your modified settings such as username/repo/version restrictions in the register module (now line 824).
• Note: No changes happened in the updater registration module, so you are free to directly copy paste your entire register/unregister module from your previous addon_updater_ops.pyinto the v1.0.2 addon_updater_ops.py file.

In the event of any problems, please open a new issue ticket.

v1.0.1 | First official release update (for testing the updater

This is the first official release of the Blender Addon Updater. See the readme for more information on how to use. Note that the updater demo addon will connect to GitHub and compare it's local version to the releases on GitHub such as this release itself.

Note that the code of v1.0.0 and v1.0.1 are identical, this secondary release is added purely to test upgrading and reverting from within the updater demo addon.

v1.0.0 | First official release

This is the first official release of the Blender Addon Updater. See the readme for more information on how to use. Note that the updater demo addon will connect to GitHub and compare it's local version to the releases on GitHub such as this release itself.