Merge 3.x into 2.x (and close 3.x branch for now)

These dependencies are not set in stone and were set mostly as a placeholder when D7 dev began, they can be safetly commented out for now as they aren't actually used. As D7 already has some popup related features, we will most likely take at least that one out before a real release.
We'll eventually use CTool's plugin architechture and perhaps its static cache feature to handle editor profiles. (Unless D7 has added this and I'm not yet aware of it.)
I would hope we can make Debug module optional, but depending on how it will be implemented I'm not sure that's possible. It's one of Sun's projects and I haven't discussed it much with him yet, but I do think he feels strongly about having it in there. We often need a lot of info to reproduce issues and if we have an automated tool to do that it could cut away many repeated questions.
Even better would be if modules extending Wysiwyg could also provide debug data via this tool, then it could be a lot easier to determine if the cause of a specific problem is in "Wysiwyg Core" or contributed code.

If we can't make a D7 release because of these dependencies when it's time, I'm all for cutting them out at least for now and postpone integration until there's a stable release of the relevant modules.

Libraries module will be able to take over a large part of Wysiwyg's current responsibilities and code when it's mature enough, and let many other modules take advantage of that. Making it optional would be more work than either going with or without it and would be a likely cause of confusion (libs loaded in different ways). Lots of modules depend on external libraries and I think most of them could benefit from a centralized way of managing these packages. When the number of modules depending on Libraries API grows, the more I think people will accept that it's a necessary part of the framework. And I think it'll provide a much better overview of what's part of Drupal and what's separate functionality added on top.

argh, major version mismatch nightmare :)

HEAD was supposed to be (or become) 7.x-3.x. IIRC, it was simply changed to 2.x just recently. However, 2.x shouldn't contain those dependencies. ;)

Two options:

1) Create a new DRUPAL-7--2 branch from HEAD, remove the dependencies.

2) Remove the dependencies from HEAD. And stop dreaming about 3.x until there's significant effort :P :-D

I vote for 1) Create a new DRUPAL-7--2 brach from HEAD, remove the dependencies.

This would make it a bit more clearer that 2.x will be the first version released for D7, and I'd like to keep dreaming a bit more. Especially since I've come quite a bit further with a clientside rewrite for 3.x. ;)

mmm, note that we can branch off into DRUPAL-7--2 at any time, whenever we want. However, I now realize that HEAD currently contains code that equals the other 3.x branches. Though the difference is marginal, I think. See attached patch.

Given that, I'm playing with the idea of merging those differences into 2.x, and leaving the current 3.x branches for D5 and D6 (possibly unpublish). That, in turn, would make HEAD 7.x-2.x for now, and consistent with the other 2.x branches.

When we start to actually have code for 3.x, then we can turn HEAD into 3.x, and only HEAD; i.e., make 7.x-3.x only.

I guess that would also heavily simplify maintenance of D5 and D6.

Yeah, HEAD can be 7.x-2.x-dev for now, then branch that off to DRUPAL-7--2 for maintenance releases when we get some real 3.x patches with features that won't go into 2.x.

The branching point between DRUPAL-6--2 (6.x-2.x-dev) and DRUPAL-6--3 (6.x-3.x-dev) doesn't really represent when 3.x work will have begun either. They've been pretty much parallel for quite a while now.
I don't know what unpublishing 6.x-3.x-dev will cause if anyone's using it, but switching "back" to 2.x-dev is no problem given they are so similar now.

I would not mind porting as much as possible from HEAD when it becomes 7.x-3.x-dev to a new branch for 6.x-3.x-dev as well, but after we know it's working for D7.

For those who haven't been following the 3.x discussions: http://groups.drupal.org/node/25112

Btw, how did you get that diff?

Looking at http://drupalcode.org/viewvc/drupal/contributions/modules/wysiwyg/CHANGE... -- how about doing a new official release for 2.x, and afterwards, committing those changes + tell other module maintainers to test?

Did a synchronization of changelogs today. My earlier suspicion holds true: http://drupalcode.org/viewvc/drupal/contributions/modules/wysiwyg/CHANGE...

I believe we can definitely merge the changes in attached patch. The only additional change that would require to be announced in some way is the dialog settings thingy.

In other words: Reconsidered - we should merge before the new release + close down 3.x for now, and instead, try to sneak as many stuff as possible into 2.x (especially 7.x-2.x).

Can someone confirm that this patch doesn't break anything?

Better title.

#8 works fine for me, including the extra check for FCKeditor format/plugins.
I cleared the cache soon after applying the patch and I'm not sure if the menu item labels changed in Admin menu before that, but they look alright now.

I agree, let's put as many of the quicker and necessary fixes in this 2.x release as possible, and once more check that we're still compatible with the latest versions of all editors. Would be annoying to have to make a new release right after it just because yet another version detection breaks.

Thanks! Alright, committed to 2.x branches.

So the only remaining question is whether attached patch breaks any modules. I don't really know whether there are any other modules that are trying to use that built-in (but very basic) dialog feature.

I don't know of any either, how about simply committing it and see if someone reacts? Would be nice to know. ;)

I'm not sure. Tweeted http://twitter.com/#!/tha_sun/status/629863073452032

If no one speaks up until tomorrow, then I guess we should simply go ahead and commit this + do the new release afterwards.

I'll try to test all editors + Drupal plugins on 2.x with this patch applied until then.

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.