Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chance of using github releases or s3 #63

Closed
KelvinSan opened this issue Jan 10, 2023 · 2 comments
Closed

Chance of using github releases or s3 #63

KelvinSan opened this issue Jan 10, 2023 · 2 comments
Assignees
Labels
question This is a request for clarification

Comments

@KelvinSan
Copy link

Is there any chance that this will support github releases, S3 buckets and release channels like pyupdater. Also, I know this sounds like an odd question but what are the chances this repo gets archived like pyupdater I would hate to have to find a new way to update python apps haha. Thanks for your time in advance

@dennisvang dennisvang added the question This is a request for clarification label Jan 11, 2023
@dennisvang
Copy link
Owner

dennisvang commented Jan 11, 2023

Is there any chance that this will support github releases, S3 buckets and release channels like pyupdater. Also, I know this sounds like an odd question but what are the chances this repo gets archived like pyupdater I would hate to have to find a new way to update python apps haha. Thanks for your time in advance

Hi @KelvinSan,

In order to keep the maintenance burden to a minimum, we aim to keep tufup lean and clean. Therefore we do not plan to include built-in support for 3rd party services like github-releases or AWS S3 buckets.

Nevertheless, tufup can be used with these services. We use it ourselves in combination with S3.

The reason for minimizing the maintenance burden is so we can keep tufup up and running for as long as possible. As we depend on tufup ourselves, we have a good reason to keep it up-and-running. Of course we also hope to get some more contributors to help with this.

... and release channels like pyupdater.

Like PyUpdater, tufup also supports "release channels," but we use PEP440 terminology. By default, the update client will search the "(final) release" channel (pyupdater's "stable"). You have the option to specify a "pre-release" channel ("a", "b", "rc") when checking for updates. Refer to the `Client.check_for_updates()' method for details:

Final releases are always included. Pre-releases are excluded by default. If pre is specified, pre-releases are included, down to the specified level. Pre-release identifiers follow the PEP440 specification, i.e. 'a', 'b', or 'rc', for alpha, beta, and release candidate, respectively.

For example, suppose your latest release is 1.1.0, and your latest pre-release is 2.0.0a3, and an app in the field has version 1.0.0. If this app checks either the default channel, the release-candidate ("rc") channel, or the beta ("b") channel, it finds 1.1.0 available. If the app checks the alpha channel ("a"), it finds 2.0.0a3.

Also have a look at the corresponding tests to see some example calls.

Note, by the way, that PyUpdater's release channels are broken. See e.g. Digital-Sapphire/PyUpdater#315 and Digital-Sapphire/PyUpdater#255. This was one of the reasons for creating tufup.

@dennisvang
Copy link
Owner

Also see this discussion: dennisvang/tufup-example#3

Repository owner locked and limited conversation to collaborators Feb 27, 2024
@dennisvang dennisvang converted this issue into discussion #115 Feb 27, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
question This is a request for clarification
Projects
None yet
Development

No branches or pull requests

2 participants