search

sparkartgroup-archive / sparkart.js

Easily interact with Sparkart's APIs via Javascript.
1 stars 0 forks source link

[#rvhdt2fP] Fixed convertDate #60

Closed djiang closed 11 years ago

djiang commented 11 years ago

Branch: rvhdt2fP-fix-convert-date Issue: #59

The month offset was off by one since new Date() takes in months from 0-11 Added Tests for then entire preprocessed date object

djiang commented 11 years ago

@jameslovejoy It looks like the current master has not been released yet, but I think the version needs to be incremented and HISTORY.md is missing the stuff you added for end_date and lapsed

jameslovejoy commented 11 years ago

I've updated HISTORY.md and tagged master as 000.007.001. Not sure if there's any other step for releasing.

https://github.com/SparkartGroupInc/sparkart.js/commit/5974b2e595ff8061382bc1a984edee8b42a6efbf

jameslovejoy commented 11 years ago

Looks good :thumbsup:

pushred commented 11 years ago

I don't think version numbers should be incremented in PRs nor should the build script be run. The problem is that until merged to master it's premature to choose a version. The correct process within GitHub seems to be to setup milestones for planned versions and then we can target specific milestones for open PRs. I've taken the liberty of starting one for 000.008.001.

Once all have been merged we can:

  1. Increment the version
  2. Run the build script
  3. Commit the results
  4. Add a tag with the version
  5. Add release notes for that tag using the Releases feature (see below)
  6. Publish those notes to the JS_Deployment SNS topic, this will start a Sparkart.js deployer instance that will fetch the latest tag and distribute the newly built version to js.sparkart.net/sparkart.js/current.js and js.sparkart.net/sparkart.js/000.###.###/sparkart.js

We should just also just start using the new Releases feature rather than HISTORY.md. Same difference! I would even motion to get rid of the compiled version in the repo and attach it as the "binary" for the releases, but being in the repo is actually crucial for things like Bower and deployment scripts.

That all kosher @fauntleroy?

djiang commented 11 years ago

Sounds good to me

djiang commented 11 years ago

I just removed my changes for updating the version #, HISTORY, and compiling the files.

Also do we have some standard for version numbers? It seems like we're just arbitrarily updating them.

jameslovejoy commented 11 years ago

I think it may be any time the API changes, we increment the middle number. Or maybe when we add/remove a widget? I guess we can do it however we want really.

Fauntleroy commented 11 years ago

http://semver.org/

pushred commented 11 years ago

We'll be adding backwards compatible functionality in this release, hence 000.008.001. Nothing arbitrary about it other than extraneous zeroes! We'll address that at a later date.