Roadmap to 1.0

[dahlbyk]

First off, huge thanks to @rkeithhill for his recent help in pushing posh-git forward! He suggested adopting SemVer and using 1.0 for the forewarned dropping of support for PowerShell 2.0. We should also consider if 1.0 is a good time to drop support for versions prior to PowerShell 5.0. Before we do that, I think it makes sense to cut a "final" (modulo minor bug fixes) pre-1.0 release.

The 1.0 milestone also give us an opportunity to revisit the many ways that posh-git is currently distributed:

• git clone <url> && .\install.ps1
• Download ZIP & .\install.ps1
• Chocolatey (which always installs or upgrades to master)
• PSGet
• PowerShell Gallery

So... tentative roadmap:

posh-git 0.7

• Fix Chocolatey package to install specific version (Chocolatey Simplification + Uninstall #358)
• Close out existing PRs that are compatible with 2.0
  • In particular, finally merge Use GitStatusCache when it's installed. #208, assuming it works with PowerShell 2.0 /cc @cmarcusreid
• Close out trivial issues that I've just been ignoring for months or years 😒
• Make prompt self-installing from the module (Move simple prompt to the module. #217)

posh-git 1.0

• Drop 2.0 support and warnings
• Review exported commands - surface area seems too big (e.g. Invoke-NullCoalescing)
• PowerShell Core support
• ANSI support?
• Remove profile.example.ps1
• Update Chocolatey install/uninstall process
• Spin off SSH Agent module (Spin off SSH Agent module? #338)
• Close remaining Linux issues (PowerShell Core on Linux support #302)

[dahlbyk]

cc @ferventcoder and @mwrock for Chocolatey input. Do you know of any other Chocolatey packages for PowerShell modules that are now available from the gallery? Would it make sense to try to restructure the package to just make sure PowerShell Gallery and the posh-git module are installed?

Update: Could Chocolatey package depend on https://chocolatey.org/packages/powershell-packagemanagement?

[dahlbyk]

cc @shiftkey for GitHub Desktop implications. Do you have any telemetry for PowerShell versions used in the wild?

[ferventcoder]

@dahlbyk I would consider PS-Get PowerShellGet separate and a release to the PowerShell Gallery means the module goes there.

If you also decide to continue releasing to Chocolatey's community repository, I would treat it differently and not just have it use PS-Get PowerShellGet. Some folks may want to install without any additional dependencies.

Side note: I've thought about adding the concept of choco install somemodule --source powershellgallery.

[ferventcoder]

Note: While I say treat them separately, there is nothing from Chocolatey's end stopping you from building a package that is compatible with both PowerShell Gallery and Chocolatey and releasing to both the PS Gallery and Chocolatey's Community Repository.

[rkeithhill]

I think it makes sense to use Chocolatey to support install on PS v2 and maybe v3/v4 as well. Although there is a PackageManagement/PowerShell install for v3/v4. I'd prefer we drop support for PSGet as it is just confusing with PowerShellGet and the latter is clearly the future for the distribution of PowerShell modules.

I'm not sure there is much to document WRT the git clone approach and I think we want to direct typical users to install from either Chocolatey for the PSGallery. These offer the benefit of providing an easy way to upgrade to a later release. For the power users, I think they'll know how to clone a GitHub repo and I'm hopeful the current README.md walks them through importing the module and configuring their prompt function.

Remove profile.example.ps1 and make prompt self-installing from the module
I'm not a big fan of the install.ps1 script approach. I used to do this with PSCX and got a fair amount of blowback from users but I'll concede that my users tended to be PowerShell "power users".

Profile scripts tend to personal / protected in nature. I mean PowerShell power users don't like you messing with their profile scripts. :-) They are also particular about which profile script imports a particular module. Some may want it in all AllUsersAllHosts, others in CurrentUserAllHosts and yet others in CurrentUserCurrentHost.

One thing we could do here, which is how I tend to "configure" my modules, is to provide a posh-git_config.ps1 file that looks like this:

Import-Module posh-git

# Set up a simple prompt that displays Git status summary info when inside of a Git repo.
function global:prompt {
    $origLastExitCode = $LASTEXITCODE

    # A UNC path has no drive so it's better to use the ProviderPath e.g. "\\server\share".
    # However for any path with a drive defined, it's better to use the Path property.
    # In this case, ProviderPath is "\LocalMachine\My"" whereas Path is "Cert:\LocalMachine\My".
    # The latter is more desirable.
    $pathInfo = $ExecutionContext.SessionState.Path.CurrentLocation
    $curPath = if ($pathInfo.Drive) { $pathInfo.Path } else { $pathInfo.ProviderPath }
    Write-Host $curPath -NoNewline

    # Write the Git status summary information to the host.
    Write-VcsStatus

    $global:LASTEXITCODE = $origLastExitCode
    "> "
}
# We could also provide several prompt variations in this file that are commented out.  The user could choose between them.

Then we could add a command like Add-PoshGitConfiguration that when run, gives the user the choice of which profile to modify, copies the file posh-git_config.ps1 to the user's $profile.CurrentUserAllHosts parent directory. Then the profile script is A) created if it doesn't exist and B) modifies the profile script to simply insert one line at the end:

. $PSScriptRoot\posh-git_config.ps1

On v2, this will need to be a bit different:

. "$(Split-Path $MyInvocation.MyCommand.Path -Parent)\posh-git_config.ps1

The command would direct the user to look at posh-git_config.ps1 and tweak their prompt as desired.

Keep in mind that many PowerShell users already have a prompt function so they are more likely to want to look at examples and integrate the posh-git status summary into their prompt function. They probably wouldn't use this command.

[rkeithhill]

Regaring semver, I think it is beneficial for PowerShellGet users to be able to easily remember/type the version number in case they want to either install or import a specific version. Import-Module posh-git -Version 0.7.0 is easier to remember than Import-Module posh-git -Version 0.7.0.20161230.

We can encode the build date into another module field if wanted. Perhaps a BuildDate/SHA1 set of fields in the PrivateData field of the manifest?

[ferventcoder]

I'd prefer we drop support for PSGet as it is just confusing with PowerShellGet and the latter is clearly the future for the distribution of PowerShell modules.

Edit - I meant PowerShellGet (not PSGet in my first statement, I specifically used "PS-Get" to separate the idea but I see the confusion). Edited.

[ferventcoder]

Import-Module posh-git -Version 0.7.0 is easier to remember

Huge fan of this as well. The date on the end I think was either using a misunderstood package fix version notation as a release version notation or it was just easier to identify for someone (maybe me a long, long time ago).

[bielawb]

I suspect that this might be hard sell and not easy thing to do - but I'd love to see posh-git implementing new way of tab-completing command elements (assuming you got v5.0+ route). TabExpansion is so v2... ;)

And a side note:

Then the profile script is A) created if it doesn't exist and B) modifies the profile script to simply insert one line at the end:

Please make sure if the profile is signed, you take that into account. To many "installers" in the wild tend to ignore that "at the end" may mean "in the part where there should not be any code".

[rkeithhill]

There's a reasonable chance that v1.0.0 will support only v5 and higher (and cross-platform as well). v0.x could be maintained on a release branch to continue to support (bug fixes only) PowerShell v2 thru v4 for some time. For the v1.0.0 version, @lzybkr may help us switch over to Register-ArgumentCompleter. :-)

RE signed profile scripts - thanks for the heads up. In that case, I think the command would probably refuse to make the change but we could emit a warning that says something to the effect:

The profile script is signed and cannot be updated since that would render the script unloadable.  
Please add the command ". $PSScriptRoot\posh-git_config.ps1" to your profile and resign it.

[ferventcoder]

Please make sure if the profile is signed, you take that into account. To many "installers" in the wild tend to ignore that "at the end" may mean "in the part where there should not be any code".

Also if you ensure the profile is signed, ensure the file is bigger than 4 bytes. Get-AuthenticodeSignature $profile on an empty file produces an error - chocolatey/choco#991

[adamralph]

From a user POV, I think it makes sense to have https://www.powershellgallery.com/ as the canonical release channel.