Version 1.x and 0.x revoked

Same problem here. admin/reports/updates even reports this problem as an error! The following text is displayed:

"Release revoked: Your currently installed release has been revoked, and is no longer available for download. Disabling everything included in this release or upgrading is strongly recommended!"

Why has the stable release (6.x-1.2) been revoked??

subscribe. This is a major warning in Update Status.

subscribe

I'm not an official co-maintainer of this project but I'll try explaining the situation.

This came out of #482736: Development snapshot status and colors broken and the great confusion about which version works with what and so on.

Alpha releases will be published periodically , and old ones unpublished.
I suggest using the Alpha releases. Any older version code will not get any updates as we need to focus on the issues which are actually related to the current code.
This is a mammoth task considering all the variations between editors people like to use, not to mention the plugins they like to use with them.
There simply aren't enough developers with time on their hands available to also take care of code which no longer represents the current state of Wysiwyg API.

Only the -dev snapshots will contain updates and they most likely will not be backported to the Alphas.
Really Critital updates are probably an exception though, but if one is discovered, the Alpha was rushed out way too early and at least I would be ashamed.
Once the current -dev has accumulated enough updates which have been tested together, there'll be a new Alpha. I'm assuming that the release of an Alpha also means it's compatible with the latest recommended releases of other closely connected modules such as Image Assist.

I don't Finals or even Release Candidates are realistic at this point since with every new editor implementation the process starts over again from scratch (though it should only affect that editor).
I don't know if the term 'Alpha' is perfectly correct in this situation. Personally I don't care what it's called as long as it's a release with a version number I know I can reference when filing an issue. Once that issue has been taken care of, I can find the new code in the -dev if I want to try it out, or I can wait until the code is stable enough for a new Alpha. Since the difference between the latest Alpha and the -dev would probably be relatively small, I might even be able to apply the relevant patch to the Alpha in the meanwhile and know it'll still be fixed when doing a real upgrade later.

Sun will have to fill in the details on all this. I only talked to him briefly about this last night but I hope I understood it correctly.

subscribe

Why was 1.x revoked? Was their a critical flaw that would damage our sites?

If 2.x is still alpha quality, can we please be allowed to continue with 1.x without being flooded with alerts telling us to upgrade. If 2.x really is stable, then could it be relabeled to something other than alpha? Beta, maybe? "Alpha" suggests that it might try to eat any site I install it on.

Sidenote:

The upgrade itself seems to be nonproblematic:

#465220: How to upgrade from 1.x to 2.0-alpha1 ?

TwoD did an awesome job in explaining the situation. (Thanks!)

- Upgrading to 2.x should work flawlessly, as explained in #465220: How to upgrade from 1.x to 2.0-alpha1 ?.

- When upgrading, you should keep the compatibility notes for other modules in mind.

- We will periodically publish alpha releases for 2.x from now on.

- Updating to further alpha releases ensures that you do not run buggy code (which may only the visitors of your site experience).

- Wysiwyg API was never "final" or "stable" and we need YOU to allow us moving forward in development.

- "alpha" describes the current development status best: The module works (as far as it does) and you can safely use it on production sites.

- Note about stability and reliability: Wysiwyg API is a rather simple connector/integration module. Besides JavaScript errors in old, buggy releases, it cannot break your site.

Daniel: I appreciate all you are doing for this module, but you're confusing us by misusing "alpha", "beta", and final release definitions. See http://en.wikipedia.org/wiki/Beta_version#Software_Development_Stages for examples of what they really mean.

Proper use of these terms will prevent the confusion evident in this issue.

Recommendations for future:

• If module's code is good enough for production use, it's not alpha or beta. It's a "real" release. Alpha or beta mean code is not stable enough for production use.
• If today's alpha is good enough for production use and is a fully usable product "as is," publish it as RC or 2.0.
• Just because you're adding features doesn't mean it has to be alpha or beta. You can add major features to a product and make new major or dot-releases. That's partly how agile development methods work. Add new features in 0.1 increments, minor features in 0.01 increments, and fundamental shifts in 1.0 increments.

Proper usage of these terms will reduce confusion and improve Drupal administrators' experience.

Concurring!
"Alpha" is very dejecting especially concerning the state of other module's alphas (=not production ready).

I agree with Aren. As a consumer of this code, I need to know clearly what I can grab and implement. When production schedules are tight, we can't all be alpha or beta testers (happy to do so when not on a critical path, and to provide feedback whenever I discover something). But subscribing to industry standard terms to indicate which code is good enough to implement is essential. We can try the dev and alpha versions on our test sites.

Revoking the code sent everyone a shocking message that inplies that something is seriously wrong, like a security issue. Proper use of terminology would let us know that a version is no longer supported, without implying that we need to go 'repair' production sites that really are not at risk.

It sounds like 2.0 should become a release or rc at this point, in the normal course of events.

I also agree with Aren. It is ironic that I only just upgraded the WYSIWYG API to 1.2 last night, and now one day later it is revoked.

Sun - I understand that there is a huge amount of work that needs to be done on this project, and it cannot possibly be easy to manage with the limited amount of help you have available. I don't want to bring you down, I just want to make you aware of what I am experiencing as a result of this revoke, and what others are also possibly experiencing.

My issue with the revoke is two-fold - I am hosting 7 sites with a single Drupal 6 installation - all sites are now complaining of a serious problem in the Status Report. I now need to reassure site owners that there is not really a critical problem with their website. The Revoke alert shows up in red as if there is a serious security risk to these websites, and from what you have explained that does not seem to be the case. This is bad - thankfully my sites are not commercial in nature or else I would have egg on my face right now.

Second - I would have installed the Alpha version last night instead of 1.2 if I had known that it wasn't really Alpha, but a Release Candidate. When I see the word Alpha associated with ANY program, I immediately translate it to mean "BUGGY AS HELL AND UNLIKELY TO WORK PROPERLY - TRY AT YOUR OWN RISK". I do not think I am alone in this.

What made it worse is that the last few times I have performed an install / upgrade of WYSIWYG, what I expected to be a 15 minute task turned into a several-hour time sink for me because things break or do not work the way I expect, and because of this I specifically set aside extra time in my busy schedule last night to install the upgrade. I don't currently have time to properly test the 2.0 release, and I am not going to just drop it in without any testing and cross my fingers and pray that nobody has problems when I do. I'm already taking up too much time that should be spent working on other projects to post this, but I think it is important that you are aware that this is not a minor issue.

Please correct your labeling system for this and future releases so that site admins do not avoid something that is production-ready for fear of it breaking our sites.

Thanks!
Mat

just a thanks and good luck to the devs, it always amazed me how many versions you guys had available. it led to confusion. hopefully this will streamline development, ease your workload and give every one concerned a common target.

good luck!

I also don't understand the maintainer's decision. The latest stable 6.x version (1.2) has just been released on May 17. Revoking the only version labeled as stable (final) so quickly after releasing it and forcing everybody to use a version labeled as unstable (alpha) - even without announcing it some time before - is not an admin-friendly way and breaks usual software releasing rules.

For me, 1.2 is currently working fine and I'm not willing to update every few days or weeks. To avoid the daily security warning alert mails and the red error on the available update page, my workaround was to just change the line

project = "wysiwyg"

to

; project = "wysiwyg"

within wysiwyg.info

Especially on sites that have non-English content, you want to update to 2.x. Actually, the latest development snapshot of 2.x. I will create a new alpha shortly.

"alpha" is the proper release suffix, because we know that there are quite some bugs.

"alpha" does not mean the code will break your site. It means exactly that the code is known to contain bugs, but may work under certain conditions.

If you want a "stable" 2.0 release, then you want to contribute to fix those bugs.

If we would create a stable release, then others would cry. See #482736: Development snapshot status and colors broken for more information.

It is kinda hard to find a solution that works for everyone and all parties involved. I am open to suggestions, as long as they are well thought-out and focus on a solution (though I think this follow-up takes it to the point). I'll ignore any comments that just complain.

Marking as fixed for now.

FWIW, I've added some notes to the installation instructions on the project page.

FWIW - I would have used 2.x already if it had been labeled beta, but now my customers are going to say, "You dumped a 1.2 final for a 2.0 alpha?!?"

The thing is, in the software world, alpha = bad, beta = I'll try it. I guess you dropped the 1.2 in order to force people to upgrade. I understand the argument that it will give more testers, but from a user experience, it's disastrous.

I'm strongly considering the #14 suggestion. It's not that I don't want to use the newer code... I just don't want to try to convince paranoid clients that alpha = good. They won't believe me (because the rest of the world says that alpha != multi-thousand dollar production sites), so I might as well save the argument until a beta, rc, or final comes out.

I know that you're working hard on this, and I do appreciate your time and effort.

-Corey

Thank you Roball, I appreciate your workaround.

Coreyp_1 - your use of the word "force" is correct. This is not a good way to establish trust or goodwill among a user base. I expect this sort of attitude from Redmond, but not from an open source community.

Sun - you also need to update the compatibility notes link you provided above in #7 - we "Passive Users" no longer have a 1.x release available to us. This is only adding to the confusion.

@yaddoshi: Handbook pages can be edited by everyone. What information do you need to do it yourself?

Sun: there is no such thing as a released product without bugs. By that logic, you're going to be stuck in alpha mode forever.

@Aren Cambre: Of course there is. There is a difference in unexpected bugs and expected bugs. You can't call something stable if you know there are bugs. Admittedly, the known bugs do not affect all users, but anyway, it's definitely not stable.

Instead of bikeshedding this, we could all use our time to fix those bugs. Thanks.

@Sun - None of us are perfect, and perhaps I initially overreacted to this situation. However, what you keep referring to as "complainers" in this thread are people who are trying to communicate with you. We understand you are busy, and we truly are grateful for all the work you do. If we didn't care, we wouldn't be bothering to bring this up to you here.

It is your prerogative to disregard what we say. However, we are human beings, and while you have certain skills that others of us may or may not possess, it does not make you any better or worse than the rest of us. How you treat others when they come to you with a grievance, however, does make an impact.

I have seen nothing positive in anything you have written here or on the other thread you referenced.

Here is the good news - I will no longer be one of your "complainers". I instead will choose from one of the other WYSIWYG modules that are available for Drupal in the hopes that their maintainers are more professional than yourself.

If you would care, then you would ask me about anything that is not clear to update the handbook pages accordingly.

Well, that's yet another way to not contribute anything. Now. Let's look whether users wanting better WYSIWYG support in Drupal will lose anything — doesn't seem so.

Any other takers? The active/passive differentiation probably won't apply anymore. Although there will be a new cutting-edge 3.x branch soon, I suspect that it will work flawlessly from the beginning.

I am one of those people who just got the revoke message. I agree this is the wrong way for this type of thing, I like the idea behind this project but you guys just made a major mistake.

Thanks
Robert

@sun by your reasoning Drupal itself should still be in Alpha: open critical bug reports in Drupal 6.x

All we were asking is that you use consistent terminology with everyone else in Drupal. You may or may not have a point about when to use the label 'alpha'. I don't feel that this is the place to force your interpretation upon others.

And, no, like yaddoshi, I haven't submitted any other comments or bugs for wysiwyg outside of this thread. Why? Because I haven't encountered any bugs. I was a happy and content user and would have happily recommended your module to anyone that asked. Now? I'm not so sure.

Hi Guys, I just visited the dalai lama last thursday...don't buzz each other, lets stay a great happy open source community. Please play transparant, and don't complaint on the person, but on the subject in open dialogue.
greetings, Martijn

I also get the warning, and even if the version number is more or less important, I think it is much more "to the point" to know version 2.x should work just fine for most of the wysiwyg APi users.

Thanks sun, keep up the good work!

Rather disappointed to see everyone bitching about this, it's really not helpful. So I'll add my support to sun and the other developers – thank you for you work.

Though not being a wysiwyg developer I'll try an clarify this further:

wysiwyg api is just that, an api for many third party wysiwyg editors (TinyMCE, FCKeditor, WYMeditor, and so on), some of those may currently have beta or even stable quality integration, others will be alpha. There just isn't a clean easy way to represent that within the current drupal.org release system, there are ways (multiple branches, constantly updated documentation) but they suck up developer time when clearly wysiwyg api developers would rather spend time developing.

This module is currently it's adolescent growth phase, one day it'll settle down to a life of respectable stable releases, but it's not ready yet. ;)

Checking my site's status I thought it was a little dramatic to see red everywhere. I, too, would have preferred 1.x to have just been left alone. But hey, my current project is full of DEV modules just to see what bugs I can track down, so an ALPHA release isn't a big deal. Just not a great way to kick off a Monday morning.

Hi

I hadn't seen this post ( I couldn't see the issue log for some reason) so I sent Sun a offlist message. Sun kindly sent me a reply and so I thought I would post it here. I hope Sun doesn't mind; I hope it is useful in understanding the team motivations and challenges.

It would be useful if the Team could have left the stable on the site and listed which editors it worked fine with.

I have no problems with the 1.1 release with TinyMCE and ImageAssist so wont be upgrading soon my production site.

Richard
NaFoF - Multi Activity Clubs in the UK

Hi Richard,

http://drupal.org/node/483582 discusses this issue.

Overall, many modules needed more time to get to D6, yes. However, in Wysiwyg API's case, that's not the issue. Wysiwyg API is a completely new approach into client-side editor integration in Drupal. We are inventing a new wheel here. By doing so, we are replacing countless of other editor integration modules and shaping a new world of content-editing experience in Drupal.

Wysiwyg API has been rewritten into 2.x, which is why 1.x and 0.x are completely unsupported. 2.x is mostly stable. And we will rewrite it again into 3.x shortly.

Feel free to add anything you have learned from this mail to above mentioned issue.

Thanks,
sun

> -----Original Message-----
> From: info@drupal.org [mailto:info@drupal.org] On Behalf Of

> Sent: Monday, June 08, 2009 8:56 PM

> Subject: [drupal.org] Wysiwyg 6.x-1.x
>
> sun,
>
> richard.e.morton (http://drupal.org/user/220191) has sent you
> a message via your contact form
> (http://drupal.org/user/54136/contact) at drupal.org.
>
> If you don't want to receive such e-mails, you can change
> your settings at http://drupal.org/user/54136.
>
> Message:
>
> Hi,
>
> I noticed that 1.x has been revoked from the site? Was that
> intended, there is no mention on the website and whether we
> should upgrade to 2.x as it is significantly better, or
> whatever. Out of interest an idea of the state of 2.x would
> be helpful - with the state of 6.x modules it is often
> required that sites run with non-gamma modules.
>
> I really am not getting at you with this next comment; but I
> am surprised by the state of 6.x modules...Especially as I
> get the feeling D7 isn't too far away from release... but I
> could be wrong. Do you recall if it took a similar amount of
> time to get D5 modules stable; I only ask because you are
> very active in the community.
>
> Thanks
>
> Richard
>

#28 (adrinux)

The issue I have isn't the code but the fact they went from support to revoked in one day without a security issue. I have had to migrate people from version 1 to 2 of some of my modules in fact I have a 2.x-rc3 right now. I also don't plan to remove support from the 1.x version overnight.

As for the question about stability. I though this is suppose to be the API? API not being stable means it is hard writing addon's when the API isn't stable.

thanks
Robert

I though this is suppose to be the API? API not being stable means it is hard writing addon's when the API isn't stable.

Exactly. And because people still use the broken API, no one can implement the API.

Anyway.

Good news: On an attempt to stop the complaints, TwoD and me worked very hard on resolving many bug reports in the past days. #474908: Teaser Break: IE8: JavaScript error being the last issue that has a chance to land in 2.x (before we will open up the 3.x branch and focus on the [mostly internal] API rewrite).

So here is the deal:

Depending on how many testing reports I will see here for the latest development snapshot of 2.x, I will consider to not create an "alpha" release. Many bug reports will make it alpha. A few will make it beta. Only positive testing results might make it more "stable".

No testing reports will make it alpha.

Before reporting any bugs, make sure they are not known already.

Time-frame? Now. The ball is moving, and we want to work on the badly required features as soon as possible.

Just to add my 2 Duccats:

* First off, I thoroughly respect the time and hard work you've put into this, you've done the Drupal community a great service by giving us a standard way to work with all WYSIWYG editors through one standard module.
* Revoking a module indicates to clients / managers that the version that is currently installed (i.e. v6.x-1.x) is no longer to be trusted and could become a security and/or stability problem, if it isn't already. This immediately injects a huge FUD factor.
* It is commonly understood that an alpha release of software is not to be trusted, is unstable and will eat kittens and your data too. While some hardened geeks and contributors will be willing to try it out, the vast majority won't touch it with a ten foot barge pole.
* Putting those two together, it's like in Cloverfield where the monster attacks the bridge as the people escape - there's a panic to upgrade but there's now no upgrade path available.
* Communication in advance of massive changes can give other community leaders & contributors a heads up to your intentions to help offset the direct workload on one developer.
* If possible, I strongly suggest posting a v1.x release and indicate it is no longer supported but only available to reduce the panic.
* Post something on the project page explaining your plan so everyone can know what's going on. Doesn't have to be long, just to say "6.x-1.x is being deprecated, stable v6.x-2.x will be out RSN but please try the current alpha releases, v6.x-3.x will have the New Cool Toys".
* Concurrently, try to get v6.x-2.x to a more stable point and release it as a beta or RC.
* With this guidance others can help by going through the issue queue and asking for issue submitters to try the v6.x-2.x release.
* I suggest not working on v6.x-3.x any further until you can push a beta or RC v6.x-2.x out the door.

Damien

The deal for getting more than an alpha is detailed in #32. Looking forward to your testing results. The development snapshot will be ready within the next 12 hours.

sun: as soon as you get the next v6.x-2.x release out I'll get it into a regularly updated in-production site.

Although I believe no one of you did any testing, I resigned and created a new stable release.

That is, because 2.0 is dead-end from now on. It works. But we will completely rewrite it. How nice! :)

Oh, and most probably we will ditch Drupal 5.x support, btw.

sun: Good going! Thanks! I'll try to get this rolled into the production site, like I mentioned. I've also got two personal sites and several in-development projects that will start to put it through its paces too.

I also want to mention that 2.0 is most probably the best release of Wysiwyg API thus far. (I'd be afraid if it was not ;)

Now, what I really wanted to mention is that you should really adhere to the module compatibility notes explained in the handbook pages.

For example, when using Image Assist, you previously used Image Assist 2, because that was compatible with Wysiwyg 1. Now, we have this shiny new Wysiwyg API 2, which introduces so called "Drupal plugins" and is thereby a corner-stone for REAL client-side editor support in Drupal. You need Image Assist 3 for that.

That's why you should update other modules accordingly when updating.

Just a note. Hopefully this saves us from a few needless support requests in the queue.

Last, but not least, I want to point all of you to #487000: Craziness!