I'd say that was a lot more than 2¢. Frankly, I'd like to say shame on you for taking such an offensive tone with people who donate their valuable free time and energy to you. It's no way to get encourage the kind of response that you want. In the future, no matter how frustrated you are, I suggest that you find the maturity to post constructive criticism instead of rants.
Also, Nathan is one of the most attentive maintainers of any piece of open source code I've ever used. I take updates frequently and have had great success in most every circumstance. And in the cases where a bug has been introduced, he has turned around fixes in record time -- most maintainers ask for patches. So perhaps, if you had taken the time to post a bug report instead of a rant, you'd already have a fix for your problem. And that's just my 2¢. Chris On Sun, Feb 28, 2010 at 10:35 PM, Michael Klishin < [email protected]> wrote: > Just want to share my opinion on HAML release management. Right now, > two people on my team are investigating form_for breakages, and > playing a "find what god damn minor version of HAML 2.2 works fine" > game. For _second_ day in a row. Why? Because HAML introduces new > features, sometimes features that target next major unreleased version > of Rails (a year plus now in the works, with _major_ changes of > internals), in its _minor_ releases. > > We did not patch HAML (readability and extensibility of HAML code is > another topic, I won't get into it here), did not patch Rails' > rendering, do not even have lots of plugins installed. Is it too much > to ask for, not break things completely in minor releases that all > other projects out there only use for bug fixing? > > Was it so hard to start a HAML 3.0 (or 2.4 or whatever) and work on > Rails 3 forward compatibility (read: satisfy your alpha geekery) > there? RSpec team, for example, started 2.0 work for Rails 3.0 in a > completely separate repository, and clearly explained that 1.x is now > for 2.x releases of Rails, while 2.x is for 3.x releases. > > Patches are welcome by the HAML team, no doubt about it. Yet HAML code > base is such a magical piece that hacks on top already pretty > complicated rendering from web frameworks, that it is pretty > challenging to wrap your head around it. And reading logs in Git does > not help one bit: because things are packed into the same branch in a > completely random manner. Rails 3.0 compatibility change here, new > SASS feature there, all on the "stable" branch. > > HAML feels like it is a piece of engineering created by designers. As > bad as design created by engineers. HAML may be markup haiku, but with > two gigatons of magic in the code base, and not following any release > practices known in the software engineering world, it feels scary to > upgrade HAML, every single time. This is sad, people. This is so sad. > > Just my 2¢. > > -- > 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=en. > > -- 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=en.
