I know this may be a simple question, but our release process is a bit unusual, so I wanted some opinions on best practices for internal package management.

Background

We have:

- Main project X (Angular app)
- Helper package P (pure JavaScript internal package)

Package P is hosted on our private npm registry and consumed by project X through package.json.

Our releases are managed as fixed product versions like 5.2.2, decided by PMs.
For every release, we create permanent branches such as:

release/5.2.2

These branches permanently diverge from master/main. Once created, nothing from master should ever flow into them again except explicitly cherry-picked fixes.

Current Process

For each release branch:

- Package P is published with the same version number as the release itself (example: 5.2.2)
- If changes are needed in package P during that release cycle, we currently:

• unpublish the package
• republish it again with the same version number

Because of this, project X only updates the dependency version once during branch creation.

Concern

Several people from Infra/DevOps have recommended following proper semantic versioning instead of overwriting the same npm version repeatedly.

However, my concern is operational overhead:

- every new publish of package P would require updating package.json in project X
- this could happen multiple times a week during active release stabilization
- it feels noisy and repetitive for release branches

### Question

What is the recommended way to manage internal npm packages in a release-branch-based workflow like this?

Should we:

- follow strict semantic versioning (5.2.2-rc.01, 5.2.1-rc.02 etc.) and update dependencies frequently? (This would mean change package.json of project P each time a new build is release)
- use dist-tags?
- automate dependency bumps somehow?
- or is republishing the same version acceptable for internal/private registries?

I’d appreciate insights from teams handling long-lived release branches with internal npm packages. Overall I don’t want to change much in my project X each time a new package P is published.