Powershell: Proper prerelease handling for install-powershell.sh and linux respositories

[DarwinJS]

I updated the installer with a bug fix so that it would recognize preview releases and now it takes them by default.

I noticed that yum update now takes subsequent preview releases - but I'm uncertain whether that is because I already took a preview or if the yum repository is serving up the latest regardless of preview status.

As a consumer of both the installer-powershell.sh script and the Microsoft Linux repositories, I think opting into previews should be under the control of the installer and default to stable only.

I can foresee how that would mean a special switch on install-powershell.sh should be necessary, but I don't know if the repository is setup properly to serve only stable by default?

[iSazonov]

/cc @TravisEz13 @SteveL-MSFT

[TravisEz13]

The linux package should be renamed to powershell-preview for non-stable releases so people can choose if they want stable or preview.
Either this issue should be changed to do that or we should file a new issue.

[DarwinJS]

I was thinking a switch for the regular package - like package installers.

[DarwinJS]

In any case it just currently pulls the latest tag and pulls the release - it needs some logic to ignore prereleases - not too challenging if it will ONLY ever be "prerelease" but if it has to support full semantic versions where any character or dash indicates a prerelease - that is more challenging.

I guess the version based tag pull could also be limited to distros that don't have a repository (still quite a few right?)

D.

[TravisEz13]

The issue is it shouldn't even be the same package in the first place. You should have to opt-in to getting the preview releases.

[DarwinJS]

install-powershell.sh is not a package - it is a method for installing packages. So I'm advocating that like package managers the script adopt the same approach of a switch which controls opt-in to prereleases.

I'm also trying to express that splitting into two scripts does not lessen development as the same logic to avoid or consume prerelease tagged packages must be built and used in both in order to continue serviing any install target that is not repo based.

So there does not seem to be speed of development nor simplicity benefits to splitting into two scripts.

[DarwinJS]

I have a follow up question - should prereleases be publish here - this is why the script finds them at all: https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/metadata.json

Should this be in a separate file for prereleases?

[DarwinJS]

It looks like the releases are not being properly tagged as prereleases - so will it will also be up to parsing to determine prerelease status?

This screenshot also shows that it is actually "releases" that are the exeption.

[iSazonov]

I wonder too why we don't set the check box.

[markekraus]

It looks like it can be change retroactively. I'll defer the actual change to @TravisEz13 or @daxian-dbw as I'm not sure if changing it would break anything.

[TravisEz13]

@daxian-dbw told me not to tag any release as pre-release. I'm not sure why.

[DarwinJS]

So two complexities push this beyond my bash skills and my current time for doing this update:

• detecting prereleases based on parsing
• getting a complete release list without json parsing

I'm not keen on the implications of trying to pull a json parser package onto target systems as that would likely disable support for a lot of systems that could otherwise work. Some of these would be in the grey area in terms of official support (like amazon linux) - but it would still seem weird to lose support over an intermediary tool requirement - especially since these are some of the toughest targets for adoption - so making it even harder for a trite reason seems like an adoption anti-pattern.

Anyone have coding experience doing github full version enumerations in pure bash?

[TravisEz13]

|distro | problem | implementation |
|------|----------|----------------|
|debian| package | package Mgr |
|redhat| package | package Mgr |
|susue | script | tar gz |
|macos| working | brew |
|amazonlinux| script| tar gz |

The problem is actually with our package where the script is using the inbox package manage. The issue is only in your script for two of the distros. I would suggest just hard coding the latest stable version in those two scripts. We should fix the package manager issues.

[DarwinJS]

A promising start:

curl https://api.github.com/repos/PowerShell/PowerShell/releases | grep -Po '"tag_name":(\d*?,|.*?[^\\]",)' | awk -F':' '{print $2}'

[DarwinJS]

Can anyone help with the statement so I can get one list of preview releases and one of product (based on presence or lack of "-" or characters) ?

Looking for arrays without the quotes and commas.

I'm not sure how just regular sorting will work of those two lists - but I could work that part out.

[DarwinJS]

Looking for feedback on this code. Only tested on CentOS.

FYI - I'm not trying to create a universal bash github version enumerator (only compat with powershell project) - so it may contain some assumptions - for instance, that all prerelease identifiers sort with the most recent last in the case an overlapping version number is used between prereleases and that all versions start with 3 leading numeric segments.

echo "All Versions"
curl https://api.github.com/repos/PowerShell/PowerShell/releases | grep -Po '"tag_name":(\d*?,|.*?[^\\]",)' | grep -Po '\d.\d[\da-z.-]*'

lastprodrelease=$(curl https://api.github.com/repos/PowerShell/PowerShell/releases | grep -Po '"tag_name":(\d*?,|.*?[^\\]",)' | grep -Po '\d+.\d+.\d+[\da-z.-]*' | grep -v '[a-z]' | sort | tail -n1)

echo "Latest Regular Version: $lastprodrelease"

lastprerelease=$(curl https://api.github.com/repos/PowerShell/PowerShell/releases | grep -Po '"tag_name":(\d*?,|.*?[^\\]",)' | grep -Po '\d+.\d+.\d+[\da-z.-]*' | grep '[a-z]' | sort | tail -n1)

echo "Latest Prerelease Version: $lastprerelease"

I have added a proper PR that uses the above code - if you have concerns about the code please add them to the PR instead of this issue.

[DarwinJS]

6405 seems to track the same thing.