Skip to content

Consistent "LTS" version naming or tagging across versions/platforms #25261

New issue
New issue
Closed
Closed
Consistent "LTS" version naming or tagging across versions/platforms#25261
Labels
Issue-Enhancementthe issue is more of a feature request than a bugResolution-AnsweredThe question is answered.WG-Maintainers-Buildspecific to affecting the build

Description

@jman61
jman (jman61)
opened on Mar 31, 2025

Summary of the new feature / enhancement

Hello Superfriends -
I would like to push out the PS 7x LTS version across a fleet of windows "Core OS" systems, but I find that:

  • with the "install-powershell.ps1" script, I can download a 'daily' release or standard latest release (ex: 7.5.0), not an LTS release.
  • If I try to look for tag like "LTS", no tag exists
  • If I try to look for a filename that contains "LTS" it only exists for select non-windows platforms
  • Naming of the download file is not consistent across platforms (see above)
    Would you be kind enough to do one or all of these?
  • Input a tag field for LTS
  • Name the files consistently across platform - dashes, dots, underscores should be used the same way.

examples:
powershell-lts_#.#.#-#_os_arch.[ext]
powershell-lts_7.4.7_win_x64.msi
powershell-lts_7.4.7_win_x86.zip
powershell-lts_7.4.7-1_deb_amd64.deb
powershell-lts_7.4.7-1_rh_x86-64.rpm
powershell-lts_7.4.7-1_linux_x64.tar.gz

Thanks for your attention, I know everyone's working hard.

Proposed technical implementation details (optional)

No response

Activity

  1. jman (jman61)
    added
    Issue-Enhancementthe issue is more of a feature request than a bug
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Mar 31, 2025

  2. rhubarb-geek-nz commented on Mar 31, 2025

    @rhubarb-geek-nz
    rhubarb-geek-nz
    on Mar 31, 2025

    A few observations

    The installation instructions for PowerShell don't explain how to get an LTS release.

    Their preferred example uses WinGet and does not offer an LTS release.

    C:>winget search Microsoft.PowerShell
Name               Id                           Version Source
---------------------------------------------------------------
PowerShell         Microsoft.PowerShell         7.5.0.0 winget
PowerShell Preview Microsoft.PowerShell.Preview 7.6.0.3 winget

    As mentioned neither does the script at tools/install-powershell.ps1 mention LTS.

    In comparison the dotnet-install-script does allow you to specify a channel, which can be set to LTS.

    Regarding the Package file naming

    First exclude deb and rpm packages. These have their own naming convention that is not defined by either Microsoft or PowerShell and should also match with the files in debian packages and rpm packages.

    For the remainder, the os-architecture pair should be the same as the .NET RID for the package, these use hyphen between the fields.

    I don't see any issue with the current filenames.

    I suggest the fix should be to align the command line options in install-powershell.ps1 with dotnet-install.ps1.

  3. 237dmitry commented on Mar 31, 2025

    @237dmitry
    237dmitry
    on Mar 31, 2025

    There are not windows lts releases in github releases. I do not know why:

    (irm https://api.github.com/repos/PowerShell/PowerShell/releases).assets.name -match 'lts'
  4. Rain Sallow (/u/ta11ow) (vexx32)
    added
    WG-Maintainers-Buildspecific to affecting the build
    on Apr 3, 2025

  5. kilasuit commented on Apr 4, 2025

    @kilasuit
    Ryan Yates (kilasuit)
    on Apr 4, 2025
    Collaborator

    Let me give some background from my knowledge, having spent plently of time with the install-powershell.ps1 script over the years and having used and extended it as blogged in this post - Installing PowerShell Side by Side for testing purposes - back in September 2023

    1. It hasn't really been a "supported" or recommended tool

      • That's why it's not mentioned in the official docs

      • It was a stop gap for installing in CI but has continued to be of use outside of it's originial intended purpose.

      • As such it's not a high priority for the team to update it when there is new functionality, like new MSI config options or like I how I had been using it to enable an install of a small selection of versions side by side whilst trying to help in reproducing bugs that have been submitted here & elsewhere (like in the PowerShell Discord/Slack community) on the versions that they had been reported on as well as ones released since then.

      • Ideally, I'd like it to be a supported, documented & importantly is a signed script that is published to the gallery, as an output from this repo as to reduce the need for others to have to produce the same script in their own organisations. But that means it needs additional work to achieve.

      • I've previously asked for scripts in this repo to be signed where possible which was entirely because of this script.

      • Note Jeff Hicks (@jdhitsolutions) has this repo & module released on the Gallery - https://github.com/jdhitsolutions/PSReleaseTools - It however does not deal with either LTS or being able to provide a specific version to install.

    2. I was in process of updating it in Update install-powershell.ps1 with more options #19884 but due to how long that PR had been in flux (it having been opened over 1 year, 9 months ago) I recently abandoned that PR, especially as there's been a long standing missing daily build as being discussed in daily builds no longer supported / built? #24566

    rhubarb-geek-nz

    A few observations

    The installation instructions for PowerShell don't explain how to get an LTS release.

    They do call out The installation commands in this article are for the latest stable release of PowerShell. To install a different version of PowerShell, adjust the command to match the version you need. which

    Their preferred example uses WinGet and does not offer an LTS release.

    Not true, Winget has an explicit --version / -v parameter that can be used to install any previous version of the Microsoft.PowerShell Package which also includes all LTS versions under the Microsoft.PowerShell ID code in winget (which are any 7.even.x release that is not marked as a preview release)

    I believe that this is also partly why 237dmitry none of the windows assets are named with lts & is in some ways also because PowerShell is internally seen to Windows using the same product-id & how the LTS/Stable releases are installed in C:\Program Files\PowerShell\7\ whereas the preview is installed in C:\Program Files\PowerShell\7-preview\ & that an upgrade from LTS -> Stable isn't something that the team wanted to do automatically for you if you had opted into Microsoft Update, as that will only update from Current LTS verison to LTS +1, so from 7.4.7 to what likely is going to be 7.4.10 & not to the 7.5.0 branch of releases.

    This is for me the right way forward as moving from LTS to STS should be informed decision to do so and helps to enable phased roll outs across individuals/organisations & is controlled by the documented environment vairiable for the update notfication behaviour
    It also allows for an easy mechanism for the move from one LTS Major version to another, like from 7.2.x to 7.4.x that happened earlier on this year.
    It also allows the move from LTS to STS and back as needed. Or so is my understanding

    So to install the LTS you need to call it as such
    winget install --id Microsoft.PowerShell -v 7.4.7.0

    I suggest the fix should be to align the command line options in install-powershell.ps1 with dotnet-install.ps1.

    They are different tools doing different albeit similar things & managed by 2 different teams from 2 very different areas at Microsoft which to me means it's very very unlikely that alignment in functionality will happen, bar the bits I've mentioned above however can some of the design of that script be

    jman (@jman61) - whilst unsupported the below sample code (I tested earlier against a Windows Sandbox) based on the blog post I authored above & the PR I abandoned would allow you to do a single machine, interactive quiet install using the MSI but doesn't have all the flags that the MSI has had added in all this time as I mentioned in 2)

    $scriptURL = 'https://raw.githubusercontent.com/kilasuit/PowerShell/update-install-powershell-script/tools/install-powershell.ps1'
$IEXScriptBlock_Part1 = "& {$(Invoke-RestMethod $scriptURL)}"
$ltsScriptBlock = "$IEXScriptBlock_Part1 -LTS -UseMSI -Quiet"
Invoke-expression $ltsScriptBlock

    If Steve Lee (@SteveL-MSFT) gives the ok for this script to be extended like I've suggested and then can be released as as signed script which is then published as it's own artifact and pushed to the gallery then I'll happily find the time to work on it either next week or the week after with any members of the team as needed to make sure that we get all the current needed features and that any possible future updates that may be needed to the script are also added in a timely manner like if there were any new additions like MSI flags etc.

    It is the PSSummit next week, so perhaps conversations there may help around all the above.

    Oh and an interesting additional area I found over the years included that you can also by using these RegKeys ask Microsoft Update to actually install PowerShell & then update it for you (not that it's well known) you can then preset all the regkeys the MSI installer would set up post install to keep the install configuration consistent between installs - this is most of what configuration options are currently missing in the install-powershell.ps1 script in its current form but would be included if Steve Lee (@SteveL-MSFT) gives the ok to do so unless there is anything coming soon enough that should make this work unnecessary like the teams ask in this discussion

    The above should help you understand the additional mechanisms that aren't documented as supported, though I think they should be documented as supported going forward, but that's for the team to decide.
    That was fun to test out and writeup and quite the trip down memory lane too & I hope is useful to all that read it & all the links.

    GitHub
    :shipit: A set of commands for working with PowerShell 7.x releases. - jdhitsolutions/PSReleaseTools

  6. jman61 commented on Apr 5, 2025

    @jman61
    jman (jman61)
    on Apr 5, 2025
    Author

    Hello all - my first github powershell post - very cool discussion, I had a feeling this had been addressed before, didn't see it.
    My goals with this request was to lessen "chasing upgrades" for a production setting, and go for a long-term-support model that I saw in the github site and elsewhere. I need automation, not manual process for this, so I'll rethink my approach.
    Responses to the comments in the order I remember them:

    • first thanks Ryan Yates (@kilasuit) for the script above to get LTS - it works! (edit: thought there was a typo, may have been my own mistake) I will try this for non-prod until I see the effect of this. I will need some modicum of support from MS updates or easier github download.
    • I will try the suggestion for "POWERSHELL_UPDATECHECK=LTS" in the system's environment variable.
    • Please accept my vote for making a change and permitting an LTS option in windows updates and downloads. I realize there's a lot of knock-on effects, but worthy. It's there for Non-Windows, should be there for the Win OS.
    • I forgot about the *nix updates naming standards - I agree their standard should be followed. Apologies!

    Thanks all for the feedback and info. - jman

  7. jman (jman61)
    closed this as completedon Apr 5, 2025
  8. microsoft-github-policy-service
    removed
    Needs-TriageThe issue is new and needs to be triaged by a work group.
    on Apr 5, 2025
  9. Ilya (iSazonov)
    added
    Resolution-AnsweredThe question is answered.
    on Apr 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Enhancementthe issue is more of a feature request than a bugResolution-AnsweredThe question is answered.WG-Maintainers-Buildspecific to affecting the build

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions