Breaking changes.

[mde]

Breaking changes.

[mde]

I'm really sorry for the inconvenience here. I really didn't intend to do anything shitty.

I don't really know of a good way other than the usual semver major version change to let people know about breaking changes. Is there some specific reason you can't continue to use v1?

[JohnMcLear]

Yea, we released with >1.0.0 in our packages.json, something we often do because we trust upstream authors not to implementing breaking changes without notifying us of deprecated methods.

Excuse me for being blunt but we're getting annoyed users...

What really needs to happen here is a new version is released by yourself. This new version rolls back the API and notifies users for X months that methods are deprecated (This can be each time they are used).. Your V2 should support methods from V1, but under a deprecated flag, that's pretty much all... Is that doable?

[mde]

I totally understand the problem with annoyed users, and I've experienced the same problem with a dependency breaking out from under me. (Although in that case, it was major breaking changes at the patch level, which is not at all something you should expect.) In any case, I'm really sorry.

I implemented this as a major version change because semver explicitly permits breaking changes between major versions. You're right that ideally I would have let people know somehow, and some sort of deprecation notice would have been a lot better experience.

Before I pushed any of this I made sure that all the v1 tests pass with the exception of filters. Is that the feature that you're depending on in your project?

[JohnMcLear]

From what I see we're not using filters so I wonder if you are lacking test coverage.. Pretty much all of our ejs logic can be seen here: https://github.com/ether/etherpad-lite/blob/develop/src/node/eejs/index.js

[mde]

Yes, possibly something edge-casey that the tests don't cover. We actually used EtherpadLite heavily early on at Yammer, and employed Peter Martischka there for a while. He's a good guy.

Can I repro the problem by just building or running the project? If not, what are some basic repro steps?

[JohnMcLear]

Yea, just building will reproduce the problem :)

[mde]

Thanks. I'll take a look.

[JohnMcLear]

Thanks @mde also sorry for being abrupt!

[mde]

All right, I've pushed a fix for this in v2.0.6. EtherpadLite's bootstrap code is directly accessing the internals of the EJS lib, using an undocumented internal variable directly. This is clearly not a great idea. (Blind updates between major versions of a supporting lib aren't nearly as heinous, but they're also a recipe for breakage. See http://semver.org/ for what types of changes to expect at different version levels.) I'll be removing this bandaid eventually. Let me know if you need some help figuring out how to clean up that bootstrap code.

[JohnMcLear]

RE help, yes please! if you can clean up the hacks we had to put in place (due to adopting so early) then that would be awesome!