Rename Project to oh-my-prompt

[kilasuit]

Whilst I tend to feel rebrands are usually much more trouble than they are worth, I feel that for this project there is plenty of merit in a rebrand to oh-my-prompt as this project has grown away from just powershell/pwsh prompts & so oh-my-posh as a name is no longer a really suitable with the expanded available featureset available to this project.

I had a quick look and thought perhaps this could be something maybe to work to for maybe a release like v30.0.0 if from reading this discussion you can see why I'm suggesting this & why this project may be a good one to use as a discussion point to try and get package registries (apt, winget, etc) to fix a rather annoying issue in software development for devs, admins & security teams.

I have a yet to be submitted PowerShell RFC with an initial draft version about how we could manage this going forward, by adding some additional metadata in PowerShell Module Manifests, allowing a bi-directional method of applying that metadata & both a FUID (Fully Unique Identifier) which is something I'm starting to hash out more details in this repo, and blogged about them in this post and this I can see being easily adapted & usable across other ecosystems, like dotnet, winget, choco, apt etc

Though totally understand if you really would rather not as this isn't a small task to undertake, but thought that it may be worth the suggestion to you for your view on this & the wider pain's we have in deprecations/superseeding/partial or full replacements for any dependencies we use as part of Modern Software Development Life Cycle (SDLC)

The Whys

Package Renames aren't handled well across almost all the different availble package managers & registries from what I have seen over the years

• Prime Example was the cutover from AzureRM to the Az PowerShell Modules as well as many others in the community like to the SharePoint PNP Community Modules to the replacement PnP.PowerShell module

This is fixable with additional metadata properties that can form a strong bi-directional link or at least a 1 directional link which I have some recommendations on how this could be done in the PowerShell ecosystem via yet to be submitted PowerShell RFC with an initial draft version which bring's the concept and use of FUID's (Fully Unique Identifiers) for use in either direction.

• It would also help further kick start discussions across package managers like winget, apt etc, about making this annoyingly brittle & painful process, less so in future which we really need to happen as this is a really frustrating from a dev, admin and security perspective.
• It also coincides with taking good practices like explicit version pinning, but making use of automated updates to dependencies like via dependabot & building & keeping a Software Bill Of Materials (SBOM) upto date
• It further would enable cross registry dependency tracking & installations which right now is a somewhat of a headache to manage.

It doesn't just cover the times where it's a simple rename of a package and the publisher is still the same.

• It would also cover the new publisher scenario, due to mergers.
• It would also cover the this package is similar to this package scenarios by allowing authors to better link together that functionality in 1 is equivilent or equal to functionality in another
• It would also cover the Maintainer gone awol, perhaps has archived the project, been hacked & other similar scenarios
• It would also cover the please use this fork of this package going forward, whether sort or long term

These are all super painful experiences and definitely not just a PowerShell ecosystem issue either.

Links

npm recommends deprecate and republish under new name
https://wiki.debian.org/RenamingPackages
https://github.com/kilasuit/FUID
https://blog.kilasuit.org/2025/09/24/announcing-fuid/
https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/

[JanDeDobbeleer]

I'm afraid it's a little too late for this. We thought about it a while back and then decided against, even if we can always find good reasons to do so.