Code for version 0.9.5

Where is source code of ciphertoken version 0.9.5?. NPM links to this repo (github.com/IGZjonasdacruz/ciphertoken), but after a npm install the code installed doesn't match at all with the code of this repository.

@luismesas this is something to take in account because in EagleNinja we are using the master source of this repository linked in the package.json like that:

   "ciphertoken": "git+https://github.com/thegameofcode/ciphertoken.git#0.0.5",

But in ciphertoken npm page(https://www.npmjs.com/package/ciphertoken) the published code links to "IGZjonasdacruz/ciphertoken" and it's not correct...

Where is the source code of version 0.9.5?
I'm working on changing the ciphertoken interface to add the callbacks like your version does.
I think that we can use the new version of ciphertoken in both projects.

[angelsanchez]

The source code is in:
https://github.com/frikiplanet/ciphertoken

There was a pull request since November with the changes.
I have closed the pull request because we cannot merge with master branch.
We can merge both changes in a development branch and we can use only one project.

[luismesas]

I did the upload to npm from that fork we made on frikiplanet organization that Kristina and me owns.

I'm with you on merging both repos to thegameofcode but I don't consider using a development branch a good solution.

Please take a look over the bible of Continous Deployment written by Martin Fowler, and consider stop using a dev branch on any project as it's againts "fail fast" & "one commit one release candidate" concepts.

On Thu, Mar 12, 2015 at 8:15 AM, d3b4s notifications@github.com wrote:

The source code is in:
https://github.com/frikiplanet/ciphertoken
There was a pull request since November with the changes.
I have closed the pull request because we cannot merge with master branch.

We can merge both changes in a development branch and we can use only one project.

Reply to this email directly or view it on GitHub:
#7 (comment)

[luismesas]

Let me explain a bit better:

Currently are two projects depending on ciphertoken: eagle ninja & cipherlayer, and two projects depending on cipherlayer. We also have three branches of ciphertoken, master & dev n thegameofcode organization and master on frikiplanet organization and npm public is linked to frikiplanet master.

With the current approach of thegameofcode master, the speed of this master is as fast as the slowest of the projects, that is, eagleninja. This means on a stall of the ciphertoken project and avoids any improvements to be done on any of the other projects until it reachs the compatibility status with the “dev” branch you propose and the merging to master.

This is the old fashioned way where internal projects of a company forces the speed of the libraries being made.

But we want ciphertoken & cipherlayer to be bigger: strajah.

For this all the development must be made on master branch, and use npm versioning in projects to select to wich version of ciphertoken or strajah you are compatible with.

On Thu, Mar 12, 2015 at 8:22 AM, Luis Mesas luis.mesas@intelygenz.com
wrote:

I did the upload to npm from that fork we made on frikiplanet organization that Kristina and me owns.
I'm with you on merging both repos to thegameofcode but I don't consider using a development branch a good solution.
Please take a look over the bible of Continous Deployment written by Martin Fowler, and consider stop using a dev branch on any project as it's againts "fail fast" & "one commit one release candidate" concepts.
On Thu, Mar 12, 2015 at 8:15 AM, d3b4s notifications@github.com wrote:

The source code is in:
https://github.com/frikiplanet/ciphertoken
There was a pull request since November with the changes.
I have closed the pull request because we cannot merge with master branch.

We can merge both changes in a development branch and we can use only one project.

Reply to this email directly or view it on GitHub:
#7 (comment)

I agree with @luismesas, as NPM favors semver instead of branching, it would be better to manage dependent projects by versioning.

Based on the conventions of semver-ftw, I think the correct way to fix this is to create version 1.0.0 with all these breaking changes instead of continuing 0.9 which is not compatible with 0.0.5.