C3: Regions don't get updated while you resize the browser window

[ferrante]

Hi,

First off, great work on the library!

My issue is: if you resize your browser window, the chart gets nicely rescaled, however regions remain in the same place. Can be noticed here: http://c3js.org/samples/region_timeseries.html

Damian

[aendrew]

Confirming bug.

[masayuki0812]

Sorry, I made this bug. I pushed the fix and will release in the next version v0.4.10.

[SamMorrowDrums]

@masayuki0812

Can I suggest that a fairly major fix like this gets added to the previous release code, and promptly added to a new release, or that new releases start as Release Candidates, and then get converted to a full release after community testing.

I'm happy to give feedback on candidate releases, and possibly try to help more! The only reason I'm commenting is that if people use Bowerwith C3 and not exact versions, i.e. ~0.4, then this leaves them in a broken state. I had to switch to the latest git commit to get the fix (and I really wanted the other updates, so I didn't want to give up on the latest release).

This library is brilliant, so I hope my comments are welcome in this regard, I understand it's a lot of work, and more project overhead with versioning is never fun, but to help C3 get the respect and trust it deserves, I think a little more caution with versions would be beneficial.

Thank you, Sam

[masayuki0812]

@SamMorrowDrums Thank you for your suggestion. Yeah, I totally agree with you and the release process should be improved much more! However, to be honest I'm not sure how it should be operated actually, so your help would be appreciated.

I'm considering to operate like this:

• Before new version release (e.g. v0.4.10), create a release candidate tag for that (e.g. v0.4.10-rc1) and update package information (e.g. package.json).
• Test the code on that tag and fix bugs or other issues if needed. After the fixes, the rc version will be incremented.
• When we confirmed it's ready to release (no bugs and no issues on that tag), create a new tag (e.g. v0.4.10) and release.

In this case, we cannot release minor bug fixes quickly, but every version should be well tested and more stable.

What do you think about this operation? Any comments would be appreciated. Thanks.

[aendrew]

@masayuki0812 @SamMorrowDrums This is a really good discussion to be having, I use C3 via bower and I generally just use the master branch as my dependency given how fast it moves.

A similar suggestion might be to take a serious look at the automated testing in the next while — it seems that a few regressive bugs have gotten through recently; when they're patched, a corresponding test should be added to the suite. A possible policy might be to add a specific test for each issue closed; alas, that would require having a much better handle on the issue queue than we do now.

Further, as the code becomes increasingly abstracted due to things like #351 and #929, a lot of these edge-case bug fixes we're dealing with might need to be revisited, or have their tests broken as a result, or whatever. Not necessarily sure how to be roadmap the above with the ongoing bug fix cycle.

[SamMorrowDrums]

I think a few of us can club together to help with this, it is the least we can do!

@masayuki0812 that sounds like a good workflow, and you can still release bug-fixes quickly, for users who understand the risks of tracking the master branch. I don't want development to be slowed, I want users who are tracking specific releases to avoid breaking changes.

Also, @aendrew is right that an automated testing badge would be great, so you can see straight away if the current master is building successfully, which we can work towards.

[masayuki0812]

Thank you for the feedback! It seems that the operation will work well, so I'll operate in that way from next release anyway.

I've been trying to add a corresponding test when I fix a bug, but it's not enough sometimes actually.. So, I'll try it more and then it leads to more stable refactoring or abstraction as @aendrew said. For the refactoring roadmap, I think we can do the same thing, the workflow using rc, and in my opinion, it seems enough to fix bugs when we find in rc version if we can add corresponding tests because rc version goes through a lot of tests in several environment and I believe the coverage will be enough after all.

[masayuki0812]

0.4.10 has been released, so please let me close. Thanks.

[raray]

Apologies for resurrecting, but either this issue was not actually fixed or there was a regression at some point. The problem can still be seen in the on-site example noted in the OP. Additionally, regions do not update when a chart is zoomed. It was noted as fixed in #1357 but is not apparent as of v0.7.11.