Client Side Javascript Package Versioning

[jakesylvestre]

I was opening up a PR to update the documentation around adonisjs/adonis-websocket-client#53 when I had a thought about the client-side API documentation. Let's say I'm using Adonis 4.1 and follow the documentation and run npm i @adonisjs/websocket-client. Adonis 4.2 is then released and @adonisjs/websocket-client continues to be updated. I'll still be referring to the 4.1 documentation which will be out of date with the version of the library I'm using.

I'm not quite sure how to solve this, but I think tying a release of these types of packages to an adonis version isn't feasible since they can be used in frontend packages. I also don't think it makes sense to update every branch with the plugin (so when 4.2 comes out, 4.1 and 4.2 because this is cumbersome (and will become more cumbersome overtime) and in the case of adonis-websocket-client the Client API and Server Api will quickly be incompatible.

One way to better tackle this might be to release 2.x of @adonisjs/websocket-client when 4.2 comes out and specify in the 4.1 documentation on install to make the packages max version 1.x but definitely think there might be a better way to tackle this.

[jakesylvestre]

#317 adds documentation to 4.1 and should be merged if this is merged

[thetutlage]

More is covered on same here adonisjs/rfcs#12. Join the discussion if you have additional questions

[jakesylvestre]

@thetutlage I still think this is a different issue (want to keep adonisjs/rfcs#12 germane). I'm mainly dealing with how we tell users in the documentation that their client side packages for things like websockets are compatible with their server side packages of websockets. That's also why I opened up the issue in docs vs discussion. Should I still bring this over to adonisjs/rfcs#12

[thetutlage]

@jakesyl Okay I get it

There are couple of ways to go about it

1. Keep the versioning of client side counter parts in sync. For example: If @adonisjs/websocket is on 2.0.0, then client will also be on 2.0.0. This does comes with some overhead, where if there is only change in the server code, we will have to bump the client version no reasons.

2. Another option is to leave it to documentation. Within the documentation, we can add a table for server and client versions compatible with each other.

[jakesylvestre]

I think 1 might be less confusing but definitely adds some overhead (might be able to tackle this via a bot). Adding it to the documentation would definitely be a lot easier.

[thetutlage]

Yeah I believe, we should let the versions grow independently. There will be a time, when I will write clients for vue, react and someone can contribute for Android, iOS too.

Documenting them within the documentation is the best way to go

[jakesylvestre]

@thetutlage, happy to take the lead on this but not sure if a table makes sense for right now. You think just adding a version to the docs for 4.1 and bumping as we go makes sense?

[thetutlage]

Yeah true, table doesn't make much sense. We can add the version to the docs for now. Can you share a PR for same?