Michael, First of all, I want to be clear that any incompatibility between Haml and the most recent Rails is a very high priority bug. If you provide me with the specifics of the breakage, I'll fix it as soon as I can and push it out in a new release. We take many steps to ensure that such incompatibilities don't happen, including running our full unit and regression test suite against all supported versions of Rails before release, but sometimes bugs slip through. I make every effort to fix them immediately after they're reported, but if you absolutely cannot afford to be the first one to find them, I suggest freezing your gem versions and updating rarely.
The goal of Haml's patch versions are threefold. First, they correct bugs, which pop up from time to time in any software. Second, they introduce deprecation warnings, to ease the transition to backwards-incompatible future versions. Finally, they maintain and introduce compatibility with the software that Haml interfaces with, primarily Ruby and Rails. This compatibility includes both stable versions and the latest development versions. It seems to be support for the latter that you disagree with. I disagree that support for development versions of Rails and Ruby doesn't belong in patch releases. I have no control over the release cycles of these projects, and only some degree of control over Haml's, since I can only work on it in my spare time. It's entirely possible that the development version of Ruby or Rails will be released before the next Haml version, and it's unacceptable to force Haml users to use the development version of Haml in order to use a stable version of Rails or Ruby. Even if Haml were to be released sooner than the other projects, I don't want to force users into the development version. It's a user's place to decide which unstable software to use, not mine. If it's possible to support the latest Rails and Ruby versions with a stable Haml -- and it is -- then that's what I'm going to do. Most of the time, support for Rails 3 or Ruby 1.9 is very minor. Even when it's larger, we make every effort to keep it well-separated from any existing stable code. The code for compatibility with XSS protection (which is not strictly an edge feature, as it's available in the stable 2.2.5 release), for instance, is separated out into its own file that's completely untouched unless XSS protection is enabled. With respect to your request for feature branches (if I'm reading your email correctly), rest assured that I use them whenever I think it useful for keeping the git history well-organized. For the stable branch, though, almost every change requires only a single commit, so feature branches are mostly not useful. I do currently have one for syntax highlighting support in the documentation, but that's a larger change than most others in the branch. I hope this helps you understand the reasoning behind Haml's releases and compatibility philosophy. Let me know if you have any more questions, about the structure of the codebase, or about anything else Haml-related. - Nathan On Sun, Feb 28, 2010 at 10:35 PM, Michael Klishin < michael.s.klis...@gmail.com> 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 h...@googlegroups.com. > To unsubscribe from this group, send email to > haml+unsubscr...@googlegroups.com <haml%2bunsubscr...@googlegroups.com>. > 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 h...@googlegroups.com. To unsubscribe from this group, send email to haml+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
