Phaser: [Repo-architecture] Use git-tag for versioning

[katsos]

This issue is a proposal for the structure of this repository.

I'd like to propose to use git tag for different versions of Phaser.
This way git log and other git features and github features like releases will be independent for each version.

You can find this repo architecture in every big project on github. Here are some example:

• Material Design Lite
• React
• Webpack

[photonstorm]

Thanks for the suggestion but I'm not sure we need it. CE is tagged in its
own repo, and there won't ever be another v2 release. The next one will be
v3 which will be a natural continuation of the versions and will replace
everything currently in here when the time is right. I don't ever want to
be in the position where we have to maintain multiple versions
simultaneously, to be honest!

[rblopes]

Actually, npm version is what you should be using before every npm publish. Running npm version will tag the repository and update the version field in package.json, no need for doing these manually ─ but don't use npm version major just yet because you'd be accidentally publishing Phaser 4 in the process :wink:

Also, check np or add these npm scripts.

"scripts": {
  "publish:patch": "npm version patch && npm publish",
  "publish:minor": "npm version minor && npm publish"
},

[photonstorm]

We use the version internally in the source, it's an available const, mixed
with Dev status flags. So setting it at publish time is too late for our
needs.

[rblopes]

I know that. But, let's think, how other devs, especially the ones in charge of the above mentioned projects, deal with this? Do they consider master always unstable and disconsider the version tag altogether? Something else?

Personally, as I publish a package in npm myself, I only worry about this when it's time to hit another release, so I just run np minor/np patch in the terminal and it's done. But that's enough for my needs.

By the way, you could still tag the repository manually and run npm version from-git before publishing, but this is very error prone.

Perhaps you should consider some other method for handling the version tag for you. Not that there's something wrong in what you've been doing until now, but you could improve that later.

[photonstorm]

Ok, let's look at Webpack: Thousands of PRs and changes made directly onto master. Significant changes sometimes merged in from other branches, but on the whole looking at their commit log, it appears most work takes place directly. When they are ready they tag and publish. They also publish lots of beta versions to npm as well (we do not). You could definitely argue that the Webpack master branch is unstable. But I guess it doesn't matter for them because the main way you install it is via npm. Unless you were working on Webpack itself there's little reason to clone the repo and build from it.

For us, npm represents a much smaller percentage of installs. Most people grab the build files or clone the repo. Our npm versions are clean, stable and properly tagged. Historically our master branch has always been stable too as we always worked in a dev branch and then merged on release. This is something we may revert back to when v3 is out and the repo has been tidied up. It definitely kept things clean but was more hassle as we'd often get PRs against the wrong branch. Undecided at the moment what approach to take, will reconsider when the time comes.

[rblopes]

I'll skip React because it is a beast of a project on its own, and Material Lite seems to be in maintenance mode, but I've found it continues on as "Material Components for the web", that employs a method akin to topic branches, a way of keeping master clean before merging back the finished changes. Also, Pixi is worth of mentioning too.

Now, you're speaking on behalf of Phaser v2 (and CE) numbers. You should expect the npm numbers to raise after v3 because Phaser will perfectly be usable as a Node library ─ that's the goal, right?

Again, let me emphasize, you're doing nothing wrong, just different ─ as well numerous other projects. But by exploring what others do, you know, may present you a few alternatives which could help you later, as well define future contribution guidelines for everyone.