I am wondering which version of node-solid-server I should install?
When using npm install -g solid-server as stated in the ReadMe and on the website, version 5.0.0-beta.2 gets installed which seems not to be stable. Actually there seems to be a bug with account registration.
As the latest stable is 4.4.0, should I actually run npm install -g solid-server@4.4.0? But shouldn’t the npm package point to the latest stable version?
I’m another applying dev user; I think they are in a bit of a firefight right now; I keep watching
https://github.com/orgs/solid/projects/1#card-14842941 and test each day delete all my folders and from scratch clone:
git clone -b release/v5.0.0 https://github.com/solid/node-solid-server.git node-solid-server
and run a bunch of tests. Hope this week they get thru their firefight and stability emerges
This should not be the case for the officially released npm package, that people are encouraged to install and use.
So, firstly, the solid server is a prototype, and that includes the 4.x series and the 5.x series will also be prototypes, so this is all just prototypes in various stages of evolution. 
There are various good reasons to run the beta, for one thing, you could be helping is drive the development forward, and you would not need to perform the migration steps that are needed from 4.x to 5.x down the road.
The 4.x series had an overly complex permissions system, which led to several flaws that had could have security implications, so there is really no option to stay there for long. 5.x doesn’t have that much practical deployment behind it, and therefore there might be issues that stems from the major change that we did in the permissions system, but it is basically a security issue that we had to address. Given that you shouldn’t stay with 4.x for long, and there is a bit of a jump from 4.x to 5.x, I’d recommend taking that leap now rather than later.
Personally, I would hope people would move along with the latest versions, as that is the most helpful in the long run, as I said, these are prototypes in stages of evolution, and the latest release is the latest stage of that evolution. Now, when we get to an actual non-prototype release, then the equation changes significantly, then remaining with an old version is an alternative, but as of now, semver regulates the version numbers and does not really reflect the maturity of the code.
That being said, it came as a surprise to me that npm would set the latest tag to what is clearly semver-marked prerelease, it doesn’t seem to be a reasonable default to me. But since it did I wouldn’t be so inclined to change it either. So, I have to admit that was mostly a mistake, but since I hope people are willing to follow along, perhaps not a serious one.
That’s why it is called a firefight: They happen; especially coming out from the academic setting and then discovering things that make you wonder how the heck they ever did work!
It’ll get there. What I was suggesting is to watch the sprint; test the release/v5.0.0 every now and then and know you’re not alone
Oh yeah. So, for the record, I had 8 years of industry experience before going back to academia. I’ve been to worse firefights than this.
I worked on my.opera.com while it was growing the fastest, and every week, you’d know that whatever problems you had on Friday would be worse on Monday… Decentralization will provide scalability properties that ensures we don’t face that kind of problems, but we’re going to need to work our way through some beta phases.
This time, we’re doing providing the software for everyone, so I hope we get together around it and run the latest until we reach a stable version.
That’s why we [should] have continuous delivery pipelines with automated provisioning and testing nowadays 
But for now I can live with the fact that it is a prototype and I will stay on whatever npm install provides and file issues as they occur.
I was in a ‘firefight’ in the late nineties; a professor who knew mine found out I automated the data collection for all our equipment. He had a technique where they applied voltage across electrodes in a bucket of specialized liquids and as they brought the electrodes together there would be big flash and explosion under the surface and these submicron perfect little spheres would gather. He was afraid the tape with the program in the Commodore 64 would give out and it was their only copy and their project would be in jeopardy. I sat there on a little stool next to the bucket, with all the power voltage and bare wires, going thru the code on the screen writing down what it did and ran the steps where it had you choose from a series of 1. 2. 3. etc options and at some point it said “Pull the lever…” So I pull the big metal lever [after all if you don’t complete a circuit…], big flash and explosion, success!
At a certain point when my butt was starting to hurt it dawned on me that with all the wires and mess not one cable or wire or connector went between the Commodore and the rest of ‘the machine’. I had to convince a group of professors with the unplugged Commodore I could pull a lever and make submicron perfect little spheres:-)