The [] change

[onli]

That 2.0.x suddenly needs an [] around parameters of the execute call breaks a lot of projects. #525 is not alone in being frustrated by this. A couple of thoughts:

1. The syntax without [] was never deprecated in a visible way. Maybe internally, but the deprecation warning was never shown when just using the gem in regular code. It should have been communicated.
2. What makes this especially hurtful is that the old code just continues to run. Even if v2.0.3 now throws an exception, projects like mine will have rescue/catch around the queries anyway because some exceptions happen often in some code paths, and exception on the db layer tend to be unhelpful after initial development. So even throwing an exception is not enough.
3. That this change was launched without that exception is a big problem. It make it seems like the impact on existing projects wasn't even considered.
4. There is no justification for this change. "I would like there to be only one way to use a particular method." is not a justification, and it's unbecoming to the ruby environment.
5. Breaking changes like this feel very out of place in the ruby world. This is not the amateur JS world, and ruby projects are normally more considerate than forcing unnecessary changes "just because".

In short, I'm disappointed in how this was handled. Maybe it could be avoided in the future? :)

[flavorjones]

@onli Thanks for your comments. I hear your frustration and I acknowledge we should have raised exceptions in 2.0.0 (but I will note that we started raising exceptions in 2.0.1, released two days later).

That said, though, maintaining libraries is challenging and time consuming for the people maintaining them, and we are allowed to make things easier for ourselves. In my opinion a major release is an opportunity to simplify the code to make it easier to maintain and reason about, and that's what we did.

So while I hear you and we probably would have done this differently if we fully understood the user impact, I also think this is open source project, provided as-is, and you haven't paid anybody for a support contract. If you want to help govern this project, you can't just show up when you have a complaint after the fact. Accusing us of not considering the impact on existing projects is insulting and demotivating. We had a conversation in the open about what we were planning for 2.0 and I don't see you participating there.

We are humans, we made our best judgement call at the time with the information we had, and you and the rest of the world needs to be OK with that (or else you can fork it, or start your own project, or vote with your feet and use another sqlite library -- you've got options).

So, to try to answer your points above:

1. Deprecation warnings were added in 2010 - FOURTEEN YEARS AGO. FOURTEEN. These were not "internal", they were emitted using Ruby's Warning.warn and the deprecation was noted in the CHANGELOG for v1.3.0. I'm not absolutely sure, but there's a good chance this was deprecated before the code you're talking about was even written.
2. As of 2.0.1, the gem raises an ArgumentError exception in these cases. I do feel the need to point out that you should probably not be rescuing ArgumentErrors in your code, this is why the library has a base exception class SQLite3::Exception. Rescue that.
3. We could have done better here, as I acknowledged above. But we added an exception as soon as we realized the negative impact, in 2.0.1 two days later.
4. The justification does not need to be anything other than "this makes maintainers' lives easier", but it sounds like we disagree on that.
5. Breaking changes are literally what a major release is for.

You're disappointed? You think we're amateurs? You think we should be more considerate? I think you need to stop externalizing the blame for things you had control over and plenty of opportunity to address.