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. On Mon, Nov 23, 2009 at 8:41 AM, Chris Eppstein <[email protected]> wrote: > 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 > > On Mon, Nov 23, 2009 at 6:01 AM, Mislav Marohnić < > [email protected]> wrote: > >> On Sun, Nov 22, 2009 at 23:15, Nathan Weizenbaum <[email protected]>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. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Haml" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected] <haml%[email protected]>. >> For more options, visit this group at >> http://groups.google.com/group/haml?hl=. >> > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <haml%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=. > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/haml?hl=.
