Closed MikeMcQuaid closed 2 months ago
Just to confirm before creating PR(s) for livecheck
blocks:
portable-ruby
version restriction in the autobump workflow or should it be handled in the livecheck
block? I tend to prefer for livecheck
to return the latest version and for tools that use the information to handle version restriction but it's maybe less of an issue since this isn't core/cask.portable-ruby
and we simply use the latest version for the other formulae, correct?Is it possible to implement the portable-ruby version restriction in the autobump workflow or should it be handled in the livecheck block?
The throttle
dsl should be able to handle this if it's set to 2?
- Is it possible to implement the
portable-ruby
version restriction in the autobump workflow or should it be handled in thelivecheck
block? I tend to prefer forlivecheck
to return the latest version and for tools that use the information to handle version restriction but it's maybe less of an issue since this isn't core/cask.
I don't feel strongly either way.
- The aforementioned version restriction only applies to
portable-ruby
and we simply use the latest version for the other formulae, correct?
Correct, the others should always be latest.
The
throttle
dsl should be able to handle this if it's set to 2?
Stupid question: would this not mean that we wouldn't get an upgrade to e.g. 3.3.2?
Stupid question: would this not mean that we wouldn't get an upgrade to e.g. 3.3.2?
You would, but I read wrong, and now realise we just want to match anything that doesn't end in .0
- so throttle
doesn't work here.
You would, but I read wrong, and now realise we just want to match anything that doesn't end in
.0
- sothrottle
doesn't work here.
Yeh, thought so, thanks for suggesting anyway though 👍🏻 ❤️
PR to add livecheck
blocks is now up at https://github.com/Homebrew/homebrew-portable-ruby/pull/204.
Ah sorry was already working on this last week 😅 and was working on autobump as a push for a no-BrewTestBot-allowed approach (https://github.com/Homebrew/actions/pull/542 was something that helped unblock that).
I've pushed what I had: https://github.com/Homebrew/homebrew-portable-ruby/tree/livecheck but I can drop this for now in favour of the other PR.
Something I hadn't looked at yet at all was: do we actually support brew bump(-formula-pr)
on resources livechecks yet (not Python)?
- Is it possible to implement the
portable-ruby
version restriction in the autobump workflow or should it be handled in thelivecheck
block? I tend to prefer forlivecheck
to return the latest version and for tools that use the information to handle version restriction but it's maybe less of an issue since this isn't core/cask.
Either approach is possible, but it will likely be easier to use Homebrew/actions/bump-packages
with it in the livecheck block.
I've pushed what I had: https://github.com/Homebrew/homebrew-portable-ruby/tree/livecheck but I can drop this for now in favour of the other PR.
It looks like your livecheck
blocks have some added benefits over my basic PR, so we should integrate some of the changes after some discussion.
I didn't use #formula
references as I wasn't sure whether homebrew/core will be tapped/available in this environment. If it is, then #formula
is the way to go (to align the checks with the core formulae).
I was wondering how we would handle openssl
version updates. If we're going to do version restriction in livecheck
strategy
blocks, then your approach makes sense.
You've opted to check https://raw.githubusercontent.com/ruby/www.ruby-lang.org/HEAD/_data/releases.yml for portable-ruby
whereas I'm checking https://www.ruby-lang.org/en/downloads/releases/. We don't want livecheck to surface a new version until the related tarball is available to download, so is there any chance that releases.yml
will be updated before the tarball is available? If so, it would probably be better to check ruby-lang.org.
- I didn't use
#formula
references as I wasn't sure whether homebrew/core will be tapped/available in this environment. If it is, then#formula
is the way to go (to align the checks with the core formulae).
It will be yeh 👍🏻
Either approach is possible, but it will likely be easier to use
Homebrew/actions/bump-packages
with it in the livecheck block.
Ok, good enough reason for me to put this in the livecheck. Should be relatively easy to just make the patch part of the URL be \d*[1-9]
@samford Could you open another PR to further iterate on the livecheck blocks as discussed here based off @Bo98's branch? Thanks ❤️
I didn't use #formula references as I wasn't sure whether homebrew/core will be tapped/available in this environment. If it is, then #formula is the way to go (to align the checks with the core formulae).
Good point. If we run in macos-latest
it shouldn't be a problem.
- I was wondering how we would handle
openssl
version updates. If we're going to do version restriction inlivecheck
strategy
blocks, then your approach makes sense.
Yeah this one is option for discussion but for the sake of avoiding regressions I felt it made sense to use the same strategy to Ruby where we avoid X.Y.0
versions. I know 3.2.0 shipped with a couple issues that we would want to have avoided. The previous branch will always still be supported at this point so seemed like a reasonable approach.
You've opted to check https://raw.githubusercontent.com/ruby/www.ruby-lang.org/HEAD/_data/releases.yml for portable-ruby whereas I'm checking https://www.ruby-lang.org/en/downloads/releases/. We don't want livecheck to surface a new version until the related tarball is available to download, so is there any chance that releases.yml will be updated before the tarball is available? If so, it would probably be better to check ruby-lang.org.
Was simply because it's better machine parseable. I don't have strong preferences so don't mind either way. The tarball link is included in the YML itself so I imagine it should be uploaded at that point as it's a separate server so non-availability is probably not a concern.
It's GitHub Pages so any changes is pushed to the branch is uploaded immediately to the website too.
Related discussion: ruby/www.ruby-lang.org#2066
Yeah this one is option for discussion but for the sake of avoiding regressions I felt it made sense to use the same strategy to Ruby where we avoid
X.Y.0
versions. I know 3.2.0 shipped with a couple issues that we would want to have avoided.
Makes sense to me 👍🏻. Maybe we avoid .0
for literally everything in here? Is that overkill?
I don't have strong preferences so don't mind either way.
Let's do whatever homebrew/core does. If we want to change things here: let's change homebrew/core first/too.
Maybe we avoid .0 for literally everything in here? Is that overkill?
Possibly. I did it for OpenSSL with the knowledge that the previous version is still supported for at least security updates. This is probably not the case for all of the others.
Could you open another PR to further iterate on the livecheck blocks
Will do (edit: https://github.com/Homebrew/homebrew-portable-ruby/pull/206).
Some of these core formulae use a GitHub release asset but don't have a GithubLatest
/GithubReleases
livecheck
block, so I'll create PRs in homebrew/core to update those formulae first to maintain the behavior (edit: https://github.com/Homebrew/homebrew-core/pull/173029).
Should be relatively easy to just make the patch part of the URL be
\d*[1-9]
That regex technically wouldn't match 10, 20, etc., so we would have to use a negative lookahead to specifically avoid .0
(e.g., (\d+\.\d+\.(?:(?!0)\d+)(?:\.\d+)*)
) if we want to use a regex-only approach instead of a strategy
block.
Let's do whatever homebrew/core does. If we want to change things here: let's change homebrew/core first/too.
homebrew/core checks https://www.ruby-lang.org/en/downloads/, since it only needs the latest version (e.g., 3.3.1 for Ruby 3.3). If we want to surface the latest non-X.X.0 version, we have to check a source that provides all versions for a given major/minor and https://www.ruby-lang.org/en/downloads/releases/ is the related page on ruby-lang.org (as used in the PR).
We could update the ruby
formula to use the approach in portable-ruby
but the downloads page is fine for that formula and we only need the releases page for portable-ruby
, so there may be something to be said for keeping the ruby
and portable-ruby
checks separate.
there may be something to be said for keeping the
ruby
andportable-ruby
checks separate.
They will always need to be at least partially different anyway to make it ignore X.Y.0
versions.
Possibly. I did it for OpenSSL with the knowledge that the previous version is still supported for at least security updates. This is probably not the case for all of the others.
Ok, just Ruby and OpenSSL is fine for me.
If we want to surface the latest non-X.X.0 version, we have to check a source that provides all versions for a given major/minor and ruby-lang.org/en/downloads/releases is the related page on ruby-lang.org (as used in the PR).
Perfect, thanks for context. A comment in the block may help here, too, when adding the "no .0
" check.
so there may be something to be said for keeping the
ruby
andportable-ruby
checks separate.
You've convinced me 👍🏻
It worked: https://github.com/Homebrew/homebrew-portable-ruby/pull/208! Great work everyone particularly @samford @chenrui333 @Bo98
We're now going to start making Portable Ruby be the newest Ruby version(s) not ending in
.0
.For example, we are now on Portable Ruby 3.3.1. We should upgrade to 3.3.2 when it is released.
When 3.4.0 is released, we should not upgrade to it. When 3.4.1 is released: we should.
This would ideally be done with
livecheck
blocks for all theportable-*
formulae in this repository and an autobump workflow that opens PRs for newportable-*
versions.We will only make a new release/upload when we have new Portable Ruby versions (bar critical security vulnerabilities).
CC @Homebrew/core @nandahkrishna @samford @chenrui333 @SMillerDev who may all be interested in helping out here.