Breaking changes planned after the 1.0 release?

[GerritWanderer]

Hey devs,

our team started 4 weeks ago working on a new reactjs application based on your starterkit and we really appreciate the work you've done to make our lifes easier.
We always try to stay in sync with the master branch, which causes specially with the 1.0 release a huge effort to upgrade our features with the new duck-like architecture.

What is your plan after the 1.0 release regarding breaking changes for existing applications?
The issue we've now is that as long as our application grows, the complexity grows similar to stay in sync.

Thanks for your feedback.

Cheers,
Gerrit

[dvdzkwsk]

@GerritWanderer so that's an interesting question, and as much as I love semver I'm not sure what 1.0.0 means for the starter kit. It would be awesome to keep it backwards compatible, but being a starter kit it's hard to distinguish breaking changes beyond the obvious. The biggest change was definitely the upgrade to Babel 6, which has been extremely problematic across the community. Perhaps the addition of CSS modules could be considered a big change as well.

Right this moment I don't have any major plans beyond project cleanup and finding a fix for the vendor hash (which seems to be a general webpack problem, not something unique to this project). Probably when Webpack 2 drops we'll try to switch to that, but I have absolutely no idea what the ETA is on that. The most important thing right now is just maintaining dependencies.

So, per your question, I've had a few ideas but nothing great to be honest. The point of the project is to give you a starting-off point rather than a long-lived framework since teams are very likely to make changes to the build process. One idea I've had is to create a system that will automatically pull in the latest build-specific code (~/bin, ~/build, ~/config), but that would only work if those files were unchanged (unlikely for bigger teams).

Since I'm clearly not much help on this, I'd like to pose the question back to you: what could we do to make your life easier? How is the configuration working out for you? What common problems do you encounter? The more perspectives we get into the design of this project the better it will be and, hopefully, easier it will be for teams such as yours to keep it up to date.

[abachuk]

I was wondering, @GerritWanderer, how do you guys stay in sync with the master branch? Do you keep this github project as one of the origins and constantly pull to your project? Thx.

[mtsr]

That’s what I’ve been doing, personally. Although I do pull to a branch initially and only merge back to my own master when it’s working.

On 22 Dec 2015, at 19:43, Alex Bachuk notifications@github.com wrote:

I was wondering, @GerritWanderer, how do you guys stay in sync with the master branch? Do you keep this github project as one of the origins and constantly pull to your project? Thx.

—
Reply to this email directly or view it on GitHub.