On Dec 14, 10:21 am, Olek Poplavsky <[email protected]> wrote: > But I do understand your point about backwards > compatibility, killing those 2 methods or one of them would be a good > change only for the 'major' release, that is allowed some non-backward > compatible changes. Backwards compatibility is good, but taking it to > the extreme (NEVER break it) stifles software.
There were actually significant changes made to import/multi_insert between Sequel 2 and Sequel 3. And absent backward compatibility issues, I may have combined the methods. However, at this point, it doesn't look likely that there will be a Sequel 4. Both the jumps from Sequel 1 to 2 and Sequel 2 to 3 brought huge improvements in the underlying design, enough to warrant serious backward compatibility breakage. I think Sequel 3's design is good enough that it's unlikely that a large enough improvement could be made to the design to justify seriously breaking backwards compatibility. I could certainly change my opinion about that in the future, but Sequel has been at 3.x for 3 of its 5 years (0.x: 10 months, 1.x: 5 months, 2.x: 11 months), so I am comfortable saying that. Note that Sequel has some backwards compatibility breakage in almost every release (documented in the release notes). It's usually small and rarely causes issues. The only Sequel 3.x release with significant backwards compatibility issues was probably Sequel 3.10 (when one_to_one associations were introduced). I take backwards compatibility pretty seriously, and I think that is a good thing. Even a lot of Sequel 0.x code could probably run on Sequel 3.x. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en.
