Let's version this!

[quicksnap]

Let's shore up any big issues and stamp a version on this. This issue covers the following:

• [ ] #96
• [x] #162
• [ ] #402
• [x] #417

Some goals:

• [x] Close any stale or resolved issues
• [ ] Try and address any open problems
• [ ] Do some code reorganization to aid in upstream tracking for #96 and #402
• [x] Pick a really cool version number

[lycon2014]

I agree let's make it happen

[justingreenberg]

@quicksnap thanks for tackling this! considering the fast-moving nature of the this repo, ecosystem and dependencies i definitely support versioning...

as far as outstanding tasks, in my opinion #402 might be a little ambitious for a first release. i think the most important issue right now is getting babel 6 integrated and stable #488. we're currently in a holding pattern until react-transform plugin is updated to support the new api (the author indicates we're probably looking at a week or two on that update)

[quicksnap]

@justingreenberg do you think we could stamp a version without upgrading to babel 6? I feel it's still a little fresh. Perhaps we can do a next version once the ecosystem around it has stabilized.

[erikras]

I agree that this is needed. I'm fine with stamping it with one now. It's never going to be "complete", of course.

Is v1.0 not "cool" enough? :smile:

[justingreenberg]

@erikras @quicksnap since we're anticipating some pretty breaking changes in the next week, maybe stamp 0.9.0 today and create a 1.0.0 milestone with #96, #162 and #417 and #488? if not we could just start with v1 today—i'm totally cool with it either way!

[erikras]

Done. v0.9.0.

Since this is not a library, it only makes vague sense to follow some semblance of semver. I'm going to need some help writing the release pages and any "migration guides", since I don't have time to follow every single improvement.

[snackycracky]

:shipit:

[justingreenberg]

@erikras that's completely understandable

the redux ecosystem is moving so quickly, i think versioning this repo is really about tracking patches and general updates as best practices continue to emerge—which is especially important for people using this as a starter. since it's not a library, i don't think we need to worry too much about migration guides.

that said, it might be a good idea to set some basic contributing guidelines ie to normalize the commit log. personally i've always been a fan of angular's commit message guidelines where commit messages generally conform to <type>(<scope>): <subject>

#459 refactor(utils/url): create url mapper utility function
#463 chore(webpack): update to isomorphic tools v2
#494 fix(babel): correct dependencies and polyfills
#510 feat(app): add react-bootstrap responsive navbar

EDIT: added in #523 (merged)

@quicksnap with respect to the babel migration, when i was putting together a PR last week all of our plugins already supported the v6 api, except typecheck (which released support yesterday) and react-transform, which should be updated this week

[quicksnap]

I still am unsure of the best way to handle something like a migration guide. This repo moves pretty fast, and I feel that's part of its value.

If we do some work on reorganizing some things, and guard against unnecessary refactoring, tracking upstream changes shouldn't be terribly hard.

[quicksnap]

@justingreenberg that's good news with babel! Worth the wait, then..

[bdefore]

I'm curious if anyone who was interested in versioning has could have a look into #626 as solving these needs. It's along the lines of consolidating parts of this project into a library. @erikras @justingreenberg @quicksnap

[quicksnap]

I'll try and take a look sometime this week--just been busy with work and unable to look at large changes.