Repository navigation
Provide a latest vanity release. #20338
Description
Name of the Distribution
All
Version of the Distribution
Stable and Preview
Package Types
- Deb
- RPM
- Tar.gz
- Snap - Stop! Please file your issue in PowerShell-Snap instead.
Processor Architecture
All
.NET Core Support
- The version and architecture of the Distribution is supported by .NET Core.
Distribution Requirements
- The version of the Distribution is supported for at least one year.
- The version of the Distribution is not an interim release or equivalent.
Exemption Justification
This refers to all releases.
Progress
- An issue has been filed to create a Docker image in PowerShell-Docker
For PowerShell Team ONLY
- Docker image created
- Docker image published
- Distribution tested
- Update
packages.microsoft.comdeployment - Lifecycle updated
- Documentation Updated
Reacted by Mr Beedell, Roke Julian Lockhart
Activity
beedell-roke commentedon Sep 24, 2023
This is for documentation like
en.opensuse.org/index.php?title=PowerShell&oldid=165673#Install_PowerShell, where it cannot be feasibly updated every time PowerShell releases a new version. Precedent exists for such vanity links, especially within GitHub Releases.mklement0 commentedon Sep 24, 2023
It's a bit confusing that you've framed your issue as a distribution request and that the issue's title talks about a release.
That said, it would indeed be useful to have abstract download links that refer to whatever release is current at the time, using a format such as:
where:
{release-type}is one of:lts,stable,preview, and perhaps evendaily{os}iswin,osx, ...{arch}isx64,arm64, ...{option}segment to target special binaries such as the ones whose release file names containfxDependentandmsixbundlewhich could automatically be translated into the corresponding specific binary file name as listed at https://github.com/PowerShell/PowerShell/releases
StevenBucher98 commentedon Sep 25, 2023
You are able to use the
https://github.com/PowerShell/PowerShell/releases/download/v<VERSION>/<SPECIFIC PACKAGE>to get to the release you may need, i.ehttps://github.com/PowerShell/PowerShell/releases/download/v7.3.7/powershell-7.3.7-1.cm.x86_64.rpm. Does that meet your scenarios?StevenBucher98 commentedon Sep 25, 2023
We also have
https://aka.ms/PowerShell-Release?tag=v<VERSION>that takes you to the releases page.mklement0 commentedon Sep 25, 2023
Steven Bucher (@StevenBucher98), assuming I understand the intent of this issue correctly:
It is about direct download links that can be used in installation commands -
https://aka.ms/PowerShell-Release?tag=v<VERSION>links aren't direct download links, but my suggestion above was to use ahttps://aka.ms/powershell-releaseprefix for the yet-to-be-implemented vanity links.NOT having to specify an explicit version number is precisely what motivated the issue: instead, abstract identifiers should dynamically refer to whatever release is the current one in the specified channel (LTS, stable, preview, daily).
See my previous comment for details on how this might be implemented.
StevenBucher98 commentedon Sep 25, 2023
Gotcha missed the "latest" part of the issue, unfortunately we don't have that at the moment but would be good to have in the future, I'll see if there is some kind of automation we can use to set this up but may be tricky to do with our currently release pipelines
kilasuit commentedon Sep 26, 2023
Whilst vanity urls for downloading releases would be great for those that want/need to have their own installation mechanisms, personally I think that we should be raising better awareness of the various install-powershell scripts in the tools folder in this repo. As not only can they remove the need for custom install mechanisms they can take care of all dependency issues too & reduce admin overheads too (so win win win all around)
Which kinda helps with this ask too, albeit in a different way entirely & as it also helps take care of installation too & whilst aren't officially documented (yet) as install methods, perhaps Steven Bucher (@StevenBucher98) we can look at getting them documented properly and not just in the repo.
Especially as the
https://aka.ms/install-powershell.ps1script & it's counter part of theinstall-powershell.shscript are already available viahttps://aka.ms/install-powershell.shAlso I've added some additional updates in this PR to the install-powershell.ps1 script (which yes needs some form of PowerShell installed already to run) & have blogged a bit about some of this in Installing PowerShell Side by Side for testing purposes which may be of help going forward/
Also as a complete aside I just tested on the latest OpenSUSE Leap 15.5 WSL distro & I was able to get pwsh installed using this oneliner
bash <(wget -O - https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/installpsh-suse.sh)(from the installpsh-suse.sh script in the tools folder)Once PowerShell was installed I was then run the following to get the Preview release (same as how I had blogged above)
Invoke-Expression "& {$(Invoke-RestMethod https://raw.githubusercontent.com/kilasuit/PowerShell/update-install-powershell-script/tools/install-powershell.ps1)} -Preview"Then run this to install the LTS release too
Invoke-Expression "& {$(Invoke-RestMethod https://raw.githubusercontent.com/kilasuit/PowerShell/update-install-powershell-script/tools/install-powershell.ps1)} -LTS"to install the LTS release too(as I noted in my blog post - this
https://raw.githubusercontent.com/kilasuit/PowerShell/update-install-powershell-script/tools/install-powershell.ps1is just until the above linked PR is merged.@RokeJulianLockhart does all of the above help you in the meantime prior to there being an available vanity url sometime in the future?
beedell-roke commentedon Sep 26, 2023
Ryan Yates (@kilasuit), no, because they're not RPMs. Unlike on Windows, most Linux users aren't used to running discrete installers with non-obvious behaviour. Installing with an RPM integrates with the system package management solutions. The sole useful solution to this is a vanity link for every item of the release, because some might need DEBs, others RPMs.
Thanks though.
kasini3000 commentedon Sep 29, 2023
rhubarb-geek-nz commentedon Nov 15, 2023
I recommend having deb and rpm for each distribution and architecture in https://packages.microsoft.com/
Then if you install the repository configuration you get the appropriate version with dependencies using the existing apt or yum commands.
This does have problems, for instance there is a conflict between the dotnet provided by the base ubuntu repository and that provided by https://packages.microsoft.com/.
From Ubuntu repository
From microsoft repository
beedell-roke commentedon Feb 4, 2025
Note that
/releases/latestis provided by GitHub, but I don't believe that this would be useful when linking to a specific file-type (like a.RPM).JustinGrote commentedon Mar 28, 2025
FYI Docker containers are no longer being maintained by the team so this issue should be closed as "wontfix"
PowerShell/Announcements#75
Hopefully runtime images will become available but for now just a note this isn't going to be fixed with the mcr.microsoft.com/powershell images
beedell-roke commentedon Mar 28, 2025
Justin Grote (@JustinGrote), I'm unfamiliar with your CI pipeline, but this is primarily about binaries packaged into OS-specific installer files. Docker images may well be released alongside, but I don't understand how that relates to this.