Hey there, are there any good practices to follow for scenarios where two people want to push a beta version for the same npm module?
The way I'm thinking about it is that we'd better communicate, merge the PRs and then push only one beta version, but I'm not fully convinced this is optimal.
Note: we don't have continuous deployment yet, we manually run npm publish.
There are milestones on Github and in similar tools.
You can use those to decide what has to be finished for a release. Then the release (and tag) can be created as soon as the milestone is at 100%.
Or at least, manual testing can start, if you have that as a separate phase.
Ben Buchanan (200ok)
I make some bits of the web.
Sounds like it might be more of a planning problem than a code problem.
If the two betas are competing - they are not really betas, they're proposals. If people can build directly from branches to test them, do that (remember you can spec a full-path git URL with
#branchnameinstead of a version number). If they must be released to test, maybe do them as two separate alpha releases published from branches. Regardless - you will need to communicate how the decision gets made and when/how one gets merged to master and released in an official version.If they're just two sequential features or updates, do two releases. Work out a roadmap so everyone knows what's going on, then follow it. If they can't be released separately, just don't release until they're both done.