Roadmap v1

[geromegrignon]

The first release of Optimus UI will focus on providing a rebranded Angular v21 compatible version:

• includes all commits included in the master branch of the archived PrimeNG repo.
• ng update support due to namespace/package renaming changes
• release of rebranded primeuix/primeicons packages to be independant from PrimeTek packages.

The goal is to release a version as soon as possible.
The version will be named v1.0.0 so won't follow Angular major version matching.
It'll help us to release major versions when needed for breaking changes.

Changes are currently merged in a new main branch, planned to be the head branch over time.

The next step will be to provide a new major version (v2.0.0) to support Angular 22.

Once done, we'll focus on bugs, then feature requests.
This last step also includes all commits ported by @gianluca-moro from the v22 rc branch. It includes alot of breaking changes (selectors removal, deprecated api removal) and we'll need to properly test ng update schematics on projects before releasing it.

We also added a link in the Contribution guide towards our AI policy.
We value all contributions but need to ensure we won't introduce bugs or regressions for existing users and we need to focus on human reviews.

[edlrod]

What's the reasoning behind not following Angular major version matching?

[geromegrignon]

By following semver syntax, only a major version should introduce breaking changes.

We have over 900 issues and a codebase still using old Angular practices so some changes might introduce breaking changes and we should not delay them to match major Angular versions if we have them ready already.

But we'll implement ng update the same way it works with Angular, to provide migration schematics so the breaking changes are handled directly without any manual action on your side.

[geromegrignon]

We'll add a matrix compatibility table in the root readme file so you know which version you can use based on your Angular project version.

[raymondcheung2]

I think it's unfortunate that this is the path chosen for versioning. Most enterprise modern Angular libs tie their major version with Angular version.

[geromegrignon]

Hi @raymondcheung2, considering we have 900+ issues and legacy Angular API within the library, being able to release major versions will be more than useful, especially knowing Angular is moving to a single yearly major release (so the next one is planned for June, not November).

[klafbang]

@raymondcheung2 I strongly disagree. It has been an issue for many years that PrimeNG tied their version to Angular. This meant that you could not upgrade Angular without 1) typically waiting a month for PrimeNG becoming available, always trying and failing to get a concrete release data from PrimeTek, and 2) having to deal with functionality changes in PrimeNG, just to stay up-to-date on Angular. Not even things like standalone components or other Angular changes, but things like a new theming system holding back compatibility with Angular 18 for months.

And that's my experience as a user; I'm sure it wasn't fun for PrimeTek to make major library changes on somebody else's schedule.

Decoupling is a very good idea: make the library indicate honest compatibility spanning multiple versions, so you can stay on a slightly older widget library while updating core components so you can decouple fixing vulnerabilities from dealing with UX things. Upgrading the PrimeNG theming SUCKED. I've not encountered issues with PrimeNG 21 on Angular 22, so there's little reason it cannot claim compatibility with it.

[Kermit]

@geromegrignon
How can we (the community 🙂) help with this process?
Maybe it would be a good idea to create issues for the tasks that need to be completed before the v21 release.
Or would you prefer to handle it yourself to avoid chaos?

[gautamgiri-dev]

@geromegrignon Agreed, happy to support the initiative.

[geromegrignon]

@Kermit @gautamgiri-dev I'll work on a set of issues to give a better overview.
Currently, it's mostly about renaming the codebase or removing paid PrimeTek products.
We've handled most of them already with @dominicbachmann, to sync to avoid endless conflicts.

[gautamgiri-dev]

@geromegrignon Thanks for the update. I was going through the issues listed under projects but as you mentioned it's more of porting and renaming. I have implemented primeng at my company and I am eager to contribute and maintain this fork. Will keep an eye on issues to contribute. Please feel free to assign any if you like.

Thanks again.

[geromegrignon]

I opened a few issues to help on the documentation already: https://github.com/openng-org/optimus-ui/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A1.0.0

I created a Milestone: v1 label to help identify our current focus.
I'm about to open more issues too.

[geromegrignon]

Also added an issue for the migration guide: #1334

[manichandra]

I opened a first small accessibility PR here: #1319

I’d like to help with accessibility as Optimus UI moves through the first release and rename work. I had this same fix open in PrimeNG before the archive along with few more, and I’ve been contributing similar accessibility fixes/reviews across UI projects, including recent USWDS work and a past merged contribution to PrimeNG.

I also ran a source-level ARIA/non-text-content scan over the inherited component code. I do not want to create issue noise during the first release push, so my proposal is:

1. Start with small reviewed PRs like the breadcrumb fix.
2. Open one audit tracking issue only if maintainers want it.
3. Work through fixes in batches, with manual review per component.

If it would help, I’m happy to take responsibility for accessibility triage/review over time: validating reports, proposing focused PRs, and helping keep regressions out of the component library.

[geromegrignon]

Hi @manichandra, thanks!

I saw your comment on Reddit, but ran out of time to answer it: I really appreciate a11y contributions.
At some point, it'll be great to have some a11y testing suite in the repository.

As you noticed, the current focus is the first release. I'm workiing on triaging existing issues and add new Milestone labels to help get a better overview of priorities.

Help is very welcome, thanks!

[manichandra]

Thanks Gerome, that sounds great.

I’ll keep the first few contributions small so they don’t distract from the first release work. My plan is to start with focused accessibility fixes like the breadcrumb PR, then wait for maintainer feedback before opening any broader tracking issue.

Longer term, I’d be happy to help maintain the accessibility area for Optimus UI: triaging a11y reports, reviewing accessibility-related PRs, and helping turn recurring checks into a test suite.

On the CI side, I’m also working on an accessibility analysis tool called aria-reach. Once it is stable enough, I can propose it as one possible CI signal here, alongside existing tools like axe/playwright-based checks. I would treat that as a separate proposal so the project can evaluate it on its own merits.

For now, I’ll focus on small reviewable PRs and align with the milestones you’re setting up.

[behdi]

@manichandra would love to help you in that endeavor mate, if you have a set of available issues.

[manichandra]

Thanks @behdi, I really appreciate the offer.
I’m manually validating the scan results first so we don’t create a noisy backlog during the v1 release work. I’ll keep the initial fixes component-scoped and wait for maintainer guidance before opening a broader accessibility tracker.
Once we have a short list of confirmed items, I’ll tag you on one or two independent issues so we can work in parallel. The first likely areas are widget state/role contracts and live-region behavior. The larger SVG set needs manual classification before we propose changes.
I’m also preparing a separate report-only accessibility CI proposal that would surface findings without blocking releases.

[dixonSolutions]

I need support for angular 22 fast, I am a startup founder, is it alright if we..not necessarily have a new version, but add support for angular 22, and if you want a new version aligned with angular, we can bump to 22...pls

[dominicbachmann]

Hi, we are planning on releasing v21 and v22 in the coming days. Would you be open to test a prerelease version of both packages in your repo?

[dixonSolutions]

Yes, happy to test the prerelease of both v21 and v22 in my repo. Let me know the package tags/versions to install (or a link to the prerelease build) and I'll get it wired in and report back with any issues.

[phiponatchi]

Hi, starting a new project those days so, when you are planning to release a package for angular 22, just tried to install the lib using npm and couldn't do it, and appreciate your efforts.

[dixonSolutions]

Hey, so I noticed you own a domain, openng.org, but you are current only deploying to vercel. You should build a main branch triggered or manually trigger deployment workflow that publishes to your subdomain: optimusui.openng.org. This will ensure branding consistency and cost nothing.

[dixonSolutions]

It is also possible to add the domain to vercel itself
https://vercel.com/docs/domains/working-with-domains/add-a-domain

[dixonSolutions]

That may be an easier solution

[geromegrignon]

Thanks for mentioning it, it's been live for a week already but missed updating the GitHub link...

[dixonSolutions]

Ahh, my mistake, site is optimus.openng.org, sorry guys