jedfoster / SassMeister

The Sass playground
http://sassmeister.com
198 stars 25 forks source link

Version visibility #4

Closed blackfalcon closed 11 years ago

blackfalcon commented 11 years ago

With the rapid development of most of these frameworks, not to mention Sass itself, it would be nice of the version number was represented. Possibly in the drop down menu?

jedfoster commented 11 years ago

Closed with eeea5f36bc

lunelson commented 10 years ago

Hey, I was about to post something about this so I'll tag it on here:

  1. version indications and comments: currently the versions of ruby sass are shown in the control panel, but those of external libraries and of libsass aren't declared, which is a drawback when users want to test things out in libs that change quickly. The compiler version is later shown in the banner comment on the gist; but not 3rd party libs. It would be ideal I think, if compiler and library versions were both shown in the code—with a comment above each @import statement perhaps (?).

EDIT: I just noticed library versions are shown in ruby but not libsass -- I suppose you'd have to retrieve the semver tags from the repo itself -- or if you are using bower you might be able to read back the .bower.json file, as it should have the version tag

  1. library updates: regarding versions, libsass is currently tagged as version 0.70 in the banner—which is out of date now—and this made me think: (a) how and when are libraries updated, and (b) is there a protocol or mechanism to notify you / request an update for external libraries? My own lib is now ahead of the one on SM and I was wondering what's a reliable and polite way to say "please update".

Thanks

jedfoster commented 10 years ago

TL;DR: Versions are important—I'll get those bugs fixed—and Twitter is the best way to let me know about updates to libraries. Still more work to do around automation

The long version:

The missing version strings in the gist front matter is a bug... Not sure when or how that happened, but I'll get a fix for it soon. Versions are important and should be prominently displayed.

Re: LibSass... This one's tough. Technically, we're using node-sass, which wraps the libsass binary for Node.js. The maintainer of node-sass does not keep that project's version in step with LibSass; LibSass is currently at 1.0.1, while node-sass is at 0.8.6. Given this situation, I decided it would be less confusing to not show a version at all, than to try to explain the discrepancy. That said, I will update the version of node-sass we use in the app.

I've been working on removing the dependence on Compass extensions for loading Sass extensions in the Ruby compilers, given the recent explosion in new libraries that are being released as Bower packages, and not Compass gems. One problem that arises when trying to surface versions of Bower packages is that not all maintainers actually put versions on their packages. So, for Bower packages without a version string, I'm using the "release" SHA as the version.

As for how and when libraries are updated: it's a manual process. Or, rather, an automated process that must be manually initiated; and once completed, a deploy must be manually initiated. I try to to do this at least once a week, but have been falling behind recently. I used to "subscribe" to all the gems we use on RubyGems so that updates would show up in my RSS feed, but there are just too many for that to be practical anymore, in addition to many libraries not being listed on RubyGems. The best way to let me know of updates to a library is Twitter. There's more work to do around managing the compilers, but once that's done, the entire update process could potentially be automated.