Axis Range overwrites Stylus Range

[MortenHofft]

I find it unfortunate that valid Stylus is invalid when using the Axis library.

$myList = range(50px, 800px, 50)

Seemingly it is overwritten by the Axis color range function.

Wouldn't it be better to use another name for the color range that Axis provides. Or is there a workaround I'm not familiar with? Either way I think that leaving Stylus function intact would be the more intuitive solution. Or maybe there is a way to overload the method name if range really is the best name for color-range.

Other than that. Thank you for a nice library - I enjoy it.

[dbox]

Hey @MortenHofft -

Thanks for letting us know. Yes this is probably my fault. Didn't realize range was protected name. I'm assuming only fix is to rename it in axis. I will look into!

[jescalan]

Same here, and thanks for the heads up. Anyone have thoughts on an alternate name? Maybe like range-input?

[dbox]

yeah that's what I was thinking

[dbox]

@Jenius I can get this updated later. I seriously doubt that many people are using range yet.

Think it's fine to just put a note in the release and make it 0.5.3?

[jescalan]

Haha definitely not. It's 0.6.0 for sure with that change, it's breaking. I'm sure there will be few issues as well, but it's only fair to be responsible!

[dbox]

cool

[dbox]

If axis was at 1.0 would we have had to make it 2.0?
On Tue, Feb 23, 2016 at 3:20 PM Jeff Escalante notifications@github.com
wrote:

Haha definitely not. It's 0.6.0 for sure with that change, it's breaking.
I'm sure there will be few issues as well, but it's only fair to be
responsible!

—
Reply to this email directly or view it on GitHub
#261 (comment).

[jescalan]

Yes indeed! It took me a while to get down with it, but major version bumps are not for big releases, just to indicate whether things break or not, that's all 😀

[dbox]

Kinda hate that. In my mind 2.0 is all new. Ahh well. I'll update in a bit
On Tue, Feb 23, 2016 at 3:36 PM Jeff Escalante notifications@github.com
wrote:

Yes indeed!

—
Reply to this email directly or view it on GitHub
#261 (comment).

[jescalan]

Yeah I have agreed with this for most of my programming career and hated it. But honestly it's more important to me to know whether my shit will possibly break than to have clean shiny version numbers at this point. I've been screwed over by a number of packages that don't follow semver carefully, and it's just not worth it. I trust a package more when it doesn't break on me than when it has major releases that always have a lot of changes.

[dbox]

Yeah, totally. I get it. At least "semver in development" helps you curtail
it slightly.
On Tue, Feb 23, 2016 at 3:47 PM Jeff Escalante notifications@github.com
wrote:

Yeah I have agreed with this for most of my programming career. But
honestly it's more important to me to know whether my shit will possibly
break than to have clean shiny version numbers at this point. I've been
screwed over by a number of packages that don't follow semver carefully,
and it's just not worth it.

—
Reply to this email directly or view it on GitHub
#261 (comment).

[jescalan]

Yeah, that's the theory. If you've done things right, releases should align that way anyway once you get to stable 😀

[dbox]

Unless you have a boneheaded contributor naming things incorrectly!

puts on cone of shame
On Tue, Feb 23, 2016 at 3:51 PM Jeff Escalante notifications@github.com
wrote:

Yeah, that's the theory. If you've done things right, releases should
align that way anyway once you get to stable [image: 😀]

—
Reply to this email directly or view it on GitHub
#261 (comment).

[jescalan]

Hahah I'm equally coned for not noticing. It happens though, not a big deal!