As I've said before, I don't see any compelling reason to split Haml branches in this way. The current practice of maintaining compatibility with all Rails versions works fine. The failures you experienced were not due to this practice; very few (if any) failures ever have been. It's not changing, and I'm not interested in discussing it any more.
- Nathan On Mon, Mar 8, 2010 at 5:03 AM, Michael Klishin <[email protected] > wrote: > On Tue, Mar 2, 2010 at 11:28 AM, Nathan Weizenbaum <[email protected]>wrote: > >> >> In summary, in my experience there are few enough compatibility problems >> caused by supporting future versions of Rails that it's hardly worth >> removing this valuable support. >> >> - Nathan >> >> > Nathan, > > I am not suggesting removing anything. Just changing the situation with > supporting all possible versions of all possible frameworks at the same > time. Specifics? If I were you, I would do the following: > > * Branch off HAML 2.4 off 2.2 and announce that it is for people who use > 2.2 with Rails 2.x, Merb 1.0.x and what is going to be Sinatra 1.0. > * Branch off HAML 2.5 off 2.2 and announce that it is for people who use > 2.2 with Rails 3.x and Sinatra-next > * Branch off HAML 2.6 off 2.3 and announce that it is for people who use > 2.3 with Rails 3.x and Sinatra-next > > Will this make life any more complex for regular Joe The Haml User? I think > this: > > * If the announcement is loud and clear, and explains reasoning, community > will spread the word pretty quickly. > > * Those who don't care won't be affected and may switch to new branches > that fit them after some time. > > * Those who do care and know what framework versions they target will > switch quickly and (hopefully) have less worries when it comes to > upgrading to the next point release of HAML on their branch. > > * It does not make things any different for HAML 3.0 which may bring > significant new incompatible features, language changes for SASS, > et cetera. It is still a release several months away if I understand it > correctly. > > You have stated that compatibility issues are important to you. If you > really mean it, consider > doing something like suggested above. You have power to do that in 30 > minutes. Ok, with announcement texts that is one hour. > Because point releases (2.4 and 2.5 are off 2.2, so I mean them) usually > have a few commits between them, Git makes maintaining 3 branches easy with > cherry-picking. And Gemcutter solved most of release pain points people had > to go through before. > > This definitely sounds a bit scary if you look at variety of MySQL versions > and flavors. It's true. But I tend to think if announcement is in the > README, on the site, and in a gem post-intall message (Cucumber uses this > practice), it will be hard to not notice it. > -- > MK > > -- > 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.
