Haml/Sass 2.2.14 Released

[Nathan Weizenbaum]

I've just released Haml and Sass 2.2.14. The changelogs are available at http://haml-lang.com/docs/yardoc/HAML_CHANGELOG.md.html and http://sass-lang.com/docs/yardoc/SASS_CHANGELOG.md.html, but there are a couple things I want to highlight in particular.

First, Sass now natively supports Rack. The details are up on my blog here: http://nex-3.com/posts/88-sass-supports-rack . In addition, I made some changes and deprecations to the internal API for dealing with SassScript Color objects, so if you have custom Sass functions that depend on those you should look into making sure they're compatible.

Enjoy!
- Nathan Weizenbaum

[Shawn Allison]

Thanks for adding the XHMTL 5 DTD. I'd been eagerly awaiting something
like that.

Keep up the great work!


On Nov 22, 5:15 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> I've just released Haml and Sass 2.2.14. The changelogs are available athttp://haml-lang.com/docs/yardoc/HAML_CHANGELOG.md.htmlandhttp://sass-lang.com/docs/yardoc/SASS_CHANGELOG.md.html, but there are a

> couple things I want to highlight in particular.
>

> First, Sass now natively supports Rack. The details are up on my blog here:http://nex-3.com/posts/88-sass-supports-rack. In addition, I made some

[Mislav Marohnić]

On Sun, Nov 22, 2009 at 23:15, Nathan Weizenbaum <nex...@gmail.com> wrote:

First, Sass now natively supports Rack. The details are up on my blog here: http://nex-3.com/posts/88-sass-supports-rack . In addition, I made some changes and deprecations to the internal API for dealing with SassScript Color objects, so if you have custom Sass functions that depend on those you should look into making sure they're compatible.

I have a problem with Haml versioning. Why are such major features and some deprecations added to a minor release? If I wrote some code and deployed it with Haml 2.2.13, keeping the version constraint as "~> 2.2.13", I don't expect it to suddenly spew out deprecation notices if I update to a newer 2.2.x version.

And yes, I did write a couple of functions dealing with Color objects. I don't want that code to break or raise warnings if it didn't in the first place.

Same problem with 2.0.10. We wrote an application with 2.0.9; months later we updated the gem on the server to 2.0.10 hoping we are being a good ruby citizen and getting bugfixes, but that in fact brought our service down, since the `haml_tag` return value was not only deprecated in that release, but designed to raise an error:

    $ echo "= haml_tag :foo" | haml _2.0.9_

    <foo></foo>

    $ echo "= haml_tag :foo" | haml _2.0.10_

    Haml error

I don't expect new features and new deprecations in minor releases. New features mean new bugs. (OK, stuff like XHML5 doctype doesn't warrant a 2.x release.) And what happened to 2.1? That release should have had the `haml_tag` raising an error on rendering the return value.

[Chris Eppstein]

No offense, mislav, but your expectations are incorrect. 2.2 continues to work with your existing code. That should be your expectation. Deprecation notices are there to warn you while it can -- while the api is frozen -- so that the next release doesn't outright break on you without warning.

Also, I don't see anything wrong with adding new features with no backwards compatibility issues in a patch release. The features that were added are there because support of new modern browsers requires them and can't wait until the more destabilizing features of 2.4 are ready.

Lastly, it seems you're not aware that Haml follows the "linux style" release numbering rules where odd minor versions denote unstable releases and even minor numbers denote stable releases. If you installed haml from source right now, you'd be running 2.3.

Sass is rapidly gaining users and we are moving quickly to meet their expectations and maintain our "market leader" status. I guess we could deprecate API changes in 2.4 and then obsolete them in 2.6, but that comes at the cost of quick progress.

In any respect, we maintain a detailed changelog, which you have obviously taken the time to read. I suggest that you wait to upgrade until you're ready to change the word "value" to "rgb" in a few places in your code.

Chris

--

You received this message because you are subscribed to the Google Groups "Haml" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to haml+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haml?hl=.

[Nathan Weizenbaum]

In general, I agree with Chris. The point of deprecation notices is to give advance warning that something is going to change, and I think getting that warning as early as possible (that is, in the next patch release after we decide on the deprecation) is a good thing. In fact, I think it outweighs the annoyance of seeing the deprecation warnings and having to decide what to do about them.

No backwards-incompatible behavioral changes will be made in patch releases. The notable exception to this is adding exceptions for cases that are in error but due to bugs have not been flagged as such in previous releases. The haml_tag change made in 2.0.10 falls under this category. "= haml_tag" was always an error, just a silent one in certain cases. I didn't expect that many people were using that in their final code -- I thought it was something that tripped up newbies more than anything. If I knew it were widely used, I would likely have deprecated it first instead.

As for new features, this is something we do avoid doing in general. We only add a feature in a patch release if it's very small, completely opt-in, and easy to implement without any refactoring that could potentially damage the stability of other parts of the system. Sometimes we make exceptions; for example, the XSS-protection feature was reasonably large, and done so that Haml would be fully Rails-compatible as soon as the new Rails version was released. But I think our history of adding small features has been quite successful in general.

I'm interested in hearing your opinions on what a better way to structure the releases, deprecations, and so forth would be.

[Wincent Colaiuta]

On 23 nov, 15:01, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
>
> I have a problem with Haml versioning. Why are such major features and some
> deprecations added to a minor release? If I wrote some code and deployed it
> with Haml 2.2.13, keeping the version constraint as "~> 2.2.13", I don't
> expect it to suddenly spew out deprecation notices if I update to a newer
> 2.2.x version.

Painful experience navigating the Ruby ecosystem has taught me to
never specify that kind of ">" version requirement if I can avoid it,
instead always requiring specific, exact versions if possible.

(This isn't something that's unique to Haml; it's a good idea with
pretty much any gem as far as I'm concerned.)

Cheers,
Wincent

[Andrew Shebanow]

I agree with Wincent that avoiding '>' dependencies is a good strategy
for app developers. But I also have to note that the linux style odd/
even version numbering scheme is not a good match with the gem version
numbering scheme we all have to live with for better or worse.

It would be great if you could move to a style more in line with other
gem-based distributions: use version numbers for stable releases, and
use "-pre" (or similar) suffices when releasing experimental stuff out
of trunk. The latter is actually rarely necessary, btw: most people
who want the latest bits are comfortable getting and building their
gems directly from a git clone.

[Rhett Sutphin]

Hi,

On Nov 25, 2009, at 10:49 AM, Andrew Shebanow wrote:

> I agree with Wincent that avoiding '>' dependencies is a good strategy
> for app developers. But I also have to note that the linux style odd/
> even version numbering scheme is not a good match with the gem version
> numbering scheme we all have to live with for better or worse.

Or, alternatively, haml could use a linux-style even/odd stable/dev
scheme with the even/odd digit the _first_ digit in the version
number. In the rubygems versioning scheme, backwards-incompatible
changes are supposed to be indicated by changing the first digit[1].
AFAICT, the goal is to only introduce backwards-incompatible changes
in haml in transitions like 2.2 -> 2.4 or 2.4 -> 2.6. This means
(like the Linux kernel, I suppose) the first digit is going to be 2
forever. Why not just drop it? This would leave the other two digits
to indicate new (backwards-compatible) features and bug fixes
separately. You could start by making 2.4.0 => 4.0.0.

Rhett

[1]: http://docs.rubygems.org/read/chapter/7

[Chris Eppstein]

I think there is a good case to be made for why the next release of Sass would be "3.0" -- it will support a new syntax and probably stylesheet optimization. But there's no reason why haml should be 3.0 in the next release -- it's hardly changed.

In any case, we've taken great pains to deprecate features in one stable release before we then take them out in the next. I don't think that approach requires a major version bump. Also, the features that have been deprecated are relatively minor... Nathan is a backwards compatibility nazi ;-)

We fully expect users to grab the source and install it, that's why source builds have a higher version than stable builds -- there is also a gem called "haml-edge" that you can use to install the cutting edge version of haml. Having a separate gem is (so far) the best solution we've found to managing preview releases that are not yet beta (pre is for a release candidate -- which we do not yet have).

Chris

--

You received this message because you are subscribed to the Google Groups "Haml" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to haml+uns...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/haml?hl=en.

[Wincent Colaiuta]

One minor point: a few people have referred to the "linux style" of
version numbering, but it's not really an ideal label for that
approach seeing as Linux itself no longer uses it (and hasn't since
2.6 came out in 2003).

http://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

Cheers,
Wincent

[Nathan Weizenbaum]

The "standard" gem versioning scheme doesn't work well with the flow of Haml development. Every non-patch release of Haml includes plenty of features and a few backwards-incompatibilities. The development versions change dramatically over time, as development versions are wont to do. Moreover, other projects (Compass prior to Sass 2.2, and currently a theme generator of Dr. Nic's, I believe) need to be able to specify dependencies on development versions. This is why we provide the haml-edge gem. But this gem wouldn't be very useful if it didn't have fine-grained versioning, which is only possible if we reserve odd-numbered releases for the development version. I don't understand why this odd/even scheme doesn't work well with gem numbering, at least in any technical sense.

The question Rhett raised as to the distinction between the major and minor versions is a valid one. Historically, we bumped the major version number when it felt right to do so - after major language changes or something like that. However, the pace of releases has slowed some since then, in part because every release tends to have reasonably major language changes (e.g. control structures in Sass 2.2, new syntax in Sass 2.4).

However, it's not clear to me what a better distinction between major/minor version numbers would be. Haml/Sass development has two tracks: the stable track, which is mostly bugfixes, and the unstable track, which is new features and backwards-incompatibilities. I don't feel any need to separate this further into three development tracks (one for major, one for minor, one for patch). Before I make any change to the semantics of the version numbers, I'd need to have a good idea of what the new semantics would be and why that would be an improvement.

One thing I am sure of: the versioning system is not going to change until after 2.4 is released. We have infrastructure in place for dealing with the stable releases under the current system that I don't want to disrupt, and 2.4 has been the version number we've been telling people to expect for quite a while now, so I'm not going to change that out from under them.

- Nathan