OriginProtocol
How to do versioning of origin.js?
[Discussion on Discord in past days about how to handle npm release schedule, incompatibility between versions of demo-dapp and orign.js]
Impacts several issues: One-line setup: https://github.com/OriginProtocol/demo-dapp/issues/105 Heroku-deploys: https://github.com/OriginProtocol/demo-dapp/issues/107
@tyleryasaka writes:
We might just want to reference a git commit in our package.json rather than the published npm module Like: "@originprotocol/origin": "github:OriginProtocol/platform#fa4bccde85120d19949ef678459fffad1fe6b74d", Or even better, start using releases more frequently and referencing a release: "@originprotocol/origin": "github:OriginProtocol/platform#v0.2.60",
@DanielVF writes:
@wanderingstan Since origin.js develop and dapp develop both grow together during sprints, this means that it's going to be rare in the near future for dapp develop branch to be able to work with npm origin.js from the end of the previous sprint. It's going to need something more recent.(edited) So we either have to release to NPM a lot, or make sure people using the dapp npm link to latest platform develop commits.(edited)
- We should definitely be releasing to NPM a lot, at least at the end of each sprint.
- As pointed our before, we could point demo-dapp to specific commits of origin.js, but IMO this feels hacky and against good versioning practice.
- This issue impacts to our other desire to have one-click-heroku-deploys (https://github.com/OriginProtocol/demo-dapp/issues/107)
- From a new developer perspective, the big concern is that first-timers (with no knowledge of our release schedule) can be up and running with no fuss. (Case in point: @LyubomirR hit this exact issue this weekend, and @b33son a few days before that: https://github.com/OriginProtocol/demo-dapp/issues/106 )
One idea
Our current "promise" is that master on demo-dapp refers to version deployed at demo.originprotoco.com. But we clearly aren't updating that often (given how much the contacts are changing.)
Could we go back to having master be our default-shown branch, with the "promise" that master branches of demo-dapp and develop are always compatible, and generally updated at the end of each sprint? (Now that we can add notes to pull requests, we can add instructions there about targeting develop for PRs?)
Instead of referencing specific commits, we can reference specific release tags (as mentioned in my quoted comment above). Of course those are just commits under the hood, but it's a lot cleaner. I don't think referencing github release tags is hacky. Github can serve as a registry just as well as npm, and I prefer it because it's more transparent. If something's not working people can go into github and figure out exactly what code is being used.
Shouldn't really matter whether we use npm or github though, as long as whatever we put in package.json is not ambiguous. It should be a specific version of the code. Then all we have to do is make sure that in both develop and master, the version of origin.js specified is compatible with that branch of the demo dapp.
The old promise doesn't make a lot of sense given how infrequently we are updating demo.originprotocol.com and that's not going to change until we have a better way to push updates new contracts without losing all of our existing listings.
Agree with @wanderingstan that our "promise" should really be that the master repos are in sync and compatible with each other. Our plan is to merge develop into master as part of our sprint release process.
I'm going to switch the master branch back to being the default on our repos. That way newcomers are guaranteed to have a working repo when they land on github and try to clone it. We'll update the PR template to remind folks to send PR's to develop instead of master.
We'll also want to put a big notice in the readme for people to work off of develop when making changes. Otherwise new contributors will use master and won't be working with the current version of the code.
