Bump @types/sequelize

[bilby91]

Closes #142

[codecov-io]

Codecov Report

Merging #143 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #143   +/-   ##
=======================================
  Coverage   96.84%   96.84%           
=======================================
  Files         100      100           
  Lines         918      918           
  Branches      124      124           
=======================================
  Hits          889      889           
  Misses          9        9           
  Partials       20       20

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3352a3f...a7f45d6. Read the comment docs.

[RobinBuschmann]

Thanks for updating :)

I've published a new version (sequelize-typescript@0.6.0-beta.0). Unfortunately it is a beta release only. The master branch also includes some other changes. I think we need a better strategy regarding feature implementations and minor adjustments - git flow could do the job.

[bilby91]

@RobinBuschmann Awesome!

I was thinking that maybe we can run publish every master change on npm under the @next tag so that people can use what's on master if they want to always. This would also fix #108 too!

As a side comment, I can help you out maintaining the project if you want to! Let me know!

[snewell92]

So moving towards something like this blog post?

[snewell92]

Another option; if the project used Git Flow with structured commit messages we could use this other package on npm.

I would like having a @next tag; in addition to that, what if we had a branch called stable, and on successful PR's into stable we ran a pipeline that published the appropriate version number to npm?

This way we get bleeding edge on master while stable always reflects what a fresh npm i sequelize-typescript would install, without requiring commit messages to be structured. This setup still gives beginners stability, but it also affords contributors the same freedom and flexibility, while still being relatively simple.

[bilby91]

I like the idea!

How would you handle the stable branch ? I guess that the "real" releases would be done manually right ? CI will publish only if the stable branch has a version that is not in npm ?

[bilby91]

Maybe we can start with the @next tag and see how that goes.

[snewell92]

The stable branch would only be manually merged into with PR's either @RobinBuschmann or a core team member initiates and accepts. A commit can be made to increment the version number (could this be automated?) to the right number before the PR is merged.

Starting with the @next tag would be ideal - we can add the stable branch with auto publish later.

So.... the next tag... should we do it?

[bilby91]

@snewell92 @RobinBuschmann I can tackle that one! The only thing is that we will need to have the available env vars on travis to publish on NPM.

[RobinBuschmann]

Hey @bilby91 @snewell92, sounds great :) Starting with the nexttag is a good idea.

When it's time to set it up, give me the key and I will put the environment variables on travis.

[bilby91]

@RobinBuschmann Awesome!

You can get the api key from ~/.npmrc in the machine you are using for releases. Then look at the authToken value. Run travis encrypt YOUR_AUTH_TOKEN to get a encrypted value of the key that we can put on the .travis.yml file.

[RobinBuschmann]

I will configure it under the settings on travis-ci.org instead - if this is ok? Then you should be able to use the key to reference the token.

See:

[bilby91]

@RobinBuschmann Yep, that should work!

[bilby91]

Hey, I started playing in one our repos https://github.com/suttna/botbuilder-slack

The idea would be the following. Every time a new stable release is created. We need to dump the version to the release with beta. So, lets say that we just published 0.6.0. After that publish we need to create a new commit that changes the version to 0.7.0-beta.

When that commit is merged into master, CI will do the following:

- git config --global -l
- git config --global user.email circleci@suttna.com
- git config --global user.name CircleCI
- npm version prerelease # (This will bump version to 0.6.0-beta.0, 1, 2, etc) 
- npm publish --tag next # (Tag the version with next so that users can do `npm install sequelize-typescript@next`
- git push --follow-tags # (Push version bump to master with tags)

For doing this, the ssh key that is in travis should have write access to the repo. Maybe we can follow this conversation in another commit.