Why doesn't github release match up with what is published to npm?

[leon]

https://www.npmjs.com/package/@epicgames-ps/lib-pixelstreamingsignalling-ue5.5
The last published version of 5.5 is 2.0.1

but on github the last release is 3.0.1
https://github.com/EpicGamesExt/PixelStreamingInfrastructure/releases/tag/UE5.5-3.0.1

Shouldn't these match up?

[lukehb]

I can see how this would cause confusion.

I'll try to clarify:

This link: https://www.npmjs.com/package/@epicgames-ps/lib-pixelstreamingsignalling-ue5.5 is for the npm package lib-pixelstreamingsignalling-ue5.5.

This link: https://github.com/EpicGamesExt/PixelStreamingInfrastructure/releases/tag/UE5.5-3.0.1 is for the version of the entire repo for the 5.5 branch.

We have a number of NPM packages these days, such as lib-pixelstreamingsignalling-ue5.5, lib-pixelstreamingfrontend-ue5.5, and lib-pixelstreamingfrontend-ui-ue5.5. These are all independently versioned, as a change in one doesn't necessarily require a change in the other and users are not forced to use all of them as they are built as libraries.

This creates a little bit of an issue for us because how do we say what the version of the entire repo is at any given release if we have multiple libraries? We decided to introduce this https://github.com/EpicGamesExt/PixelStreamingInfrastructure/blob/UE5.5/RELEASE_VERSION file that tracks the version of the entire branch.

So long story short, the last published version of lib signalling for UE 5.5 is 2.0.1 but the last published version of this entire repo for UE 5.5 is 3.0.1.

The versions are not tied to each other.

[leon]

I understand,
I would suggest doing it either way, not both.

If all of the separate libraries are versioned together they should have the same version on github.
much like how https://github.com/nrwl/nx/releases do their releases.
It's easy to follow along, and you can check their github release page to get a good overview of all changes to all packages at once.

if you are going to stick to having separate versions, the logical thing would be to have separate releases of the individual packages on github as well. so that we can get separate change logs.

the main thing for me is being able to subscribe to github releases and get a good understanding of what bugs have been fixed in what versions on npm and if it's something I need to take action from.

At the moment I do not know what has been fixed in what version.

The above are of course just suggestions but I wanted to put my thoughts out there so you could understand me more :)

[lukehb]

@leon

We've been thinking on this - how do you feel about us publishing a changelog with our published NPM packages?

That should give you something akin to this:

the main thing for me is being able to subscribe to github releases and get a good understanding of what bugs have been fixed in what versions on npm and if it's something I need to take action from

[leon]

Could you expand on that a bit.
do you mean that you would have a separate CHANGELOG.md per folder in the repo?

[lukehb]

Yeah exactly that (or something very close)

[leon]

It would solve the problem knowing what changes where done to the separate libraries.

If each library would not have a specific tag on github it will be hard to do a diff between versions.

I also see a problem where if the libraries are not released and tested in unison, I might be running different versions of frontend or ui, which are not compatible with each other.

Since they are going to be used together as a whole, to me it would make sense keeping their versions in sync.

[lukehb]

I was thinking we might include the commit ranges for each of the changelog versions so we could bisect regressions and users could see what changes went into a release. Additionally, as for frontend UI and frontend library compatibility, the UI library specifies the version of the frontend library it should be used with as a peer dependency in the package json, npm should enforce this.

…

On Mon, 25 Nov 2024, 7:41 pm Leon Radley, ***@***.***> wrote: It would solve the problem knowing what changes where done to the separate libraries. If each library would not have a specific tag on github it will be hard to do a diff between versions. I also see a problem where if the libraries are not released and tested in unison, I might be running different versions of frontend or ui, which are not compatible with each other. Since they are going to be used together as a whole, to me it would make sense keeping their versions in sync. — Reply to this email directly, view it on GitHub <#313 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJIYXVU4NZP6IRPFUJRM7D2CLWGNAVCNFSM6AAAAABRVYGYPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJXGQZTIMRVHA> . You are receiving this because you modified the open/close state.Message ID: <EpicGamesExt/PixelStreamingInfrastructure/issues/313/2497434258@ github.com>

[lukehb]

If we sync all the packages to the same version, this isn't ideal for semver, which we try to follow. Imagine the ui library has a major version bump for an API breaking change, we then have to bump our signalling library to the same major version - the two libraries are unrelated and share no common code. For consumers of the signalling library they now have to accept a major change in order to accept future upgrades on a library that hasn't materially changed. On Mon, 25 Nov 2024, 8:30 pm Luke Bermingham, ***@***.***> wrote:

…

I was thinking we might include the commit ranges for each of the changelog versions so we could bisect regressions and users could see what changes went into a release. Additionally, as for frontend UI and frontend library compatibility, the UI library specifies the version of the frontend library it should be used with as a peer dependency in the package json, npm should enforce this. On Mon, 25 Nov 2024, 7:41 pm Leon Radley, ***@***.***> wrote: > It would solve the problem knowing what changes where done to the > separate libraries. > > If each library would not have a specific tag on github it will be hard > to do a diff between versions. > > I also see a problem where if the libraries are not released and tested > in unison, I might be running different versions of frontend or ui, which > are not compatible with each other. > > Since they are going to be used together as a whole, to me it would make > sense keeping their versions in sync. > > — > Reply to this email directly, view it on GitHub > <#313 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAJIYXVU4NZP6IRPFUJRM7D2CLWGNAVCNFSM6AAAAABRVYGYPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJXGQZTIMRVHA> > . > You are receiving this because you modified the open/close state.Message > ID: <EpicGamesExt/PixelStreamingInfrastructure/issues/313/2497434258@ > github.com> >

[leon]

That sounds good 👍

[lukehb]

Okay we have come up with a plan in #348 - so I am closing this one out.

@leon If you would like to make a PR for #348 as per our plan we would gladly review it. For now it is a backlogged task for us.