FlashDevelop is a mess right now

[neuronix]

Last official release is months old and unusable because of a major AS3 related bug that affects auto-completion.

On the AS3 side, every single development build since has been bug ridden, every single patch has introduced new bugs and now the last one has broken the "Test Project" button.

I understand FD is an open source project, fueled by the good will and free time of a few contributors and that FD is no longer the main focus since HaxeDevelop was started. But there are still many people out there relying on FD for AS3 development and FD has never been so unstable and unreliable.

Could you please take a break on features and refactoring for HD and release an official, stable and properly tested version of FD for AS3 development?

Edit: clarified that the issue is related to AS3 development, not FD/HD in general since Haxe support seems fine.

[gene-pavlovsky]

Disclaimer: I'm a small-time contributor to FD and anything I say below might be wrong or at odds with the opinions of the project maintainers.

HaxeDevelop is not a separate project or a fork, it's just a special build with Flash-related parts removed. Personally I've been using FlashDevelop for Flash/ActionScript development for years, and when I started to work with Haxe, I kept using FlashDevelop, not HaxeDevelop (not that there's anything wrong with the latter). At work, we have 10+ developers using FlashDevelop for Haxe web development, and a couple for Flash/Flex desktop app development. I'm also using FlashDevelop for Flash mobile app development at home. I'm usually running the latest development build.

Perhaps what you meant by mentioning HD vs FD, is that many recent PRs were related to Haxe, not AS3, which is true. In the past few months there were some general (non Haxe-specific) bugfixes for quite old but annoying issues, which is why I prefer to run development builds rather than waiting for release versions.

From my side I didn't notice an unusual increase in the number of bugs - there is "normal" amount of bugs, most of them not being a big deal. There are sometimes "blockers" from time to time, but they were fixed rather quickly.

As you correctly mentioned, this is an open-source project, every contributor has a day job and other responsibilities, meaning there is only so much time that can be dedicated to developing, fixing and testing. As for testing, there are more and more automated unit tests being added all the time. Those can help catch some problems with individual components, but FD is a rather big and complex IDE with many interconnected features. There are so many ways it can be used, it's impossible to test all the various scenarios when things can go wrong.
Unlike a company that can afford to hire QA engineers to write extensive test plans, create functional tests and perform manual tests all day long, open source projects have to rely more on the users to provide feedback. It's a community effort, if everyone contributes a bit, the result can be good. You are very welcome to contribute yourself, you can start with reporting the exact issues you are having. Since I started using FD years ago, I've submitted over a hundred issues, and I keep doing that (the guys might really hate me!). I never learned C#, .NET or Windows programming, but at some point I figured the particular issue I had at the moment should be easy to find and fix (sometimes if you want to do something, the fastest/best way is to do it yourself). So I downloaded the free MS Visual Studio Community Edition, forked the FD repo and started debugging. Shortly after that I submitted my first PR. I don't feel confident to create some new feature from scratch, but tracking down some run-time exception or why some particular feature doesn't work is usually just a matter of using the debugger, and the code is generally quite readable.

P.S. I also think we should make releases more often. They are often not much more stable than the development branch, so what's the point of waiting long between releases?

[neuronix]

@gene-pavlovsky The bugs I am referring to seem to only affect AS3 support and seem to have appeared because of underlying refactoring to improve Haxe support.

It's great that there is lots of work going into Haxedevelop, Haxe is the way to go, and I understand that if contributors are investing in Haxe, then that's their main focus and they aren't going to be testing the AS3 support for every commit. However, for pure AS3 use, FD has recently been a real pain to use due to these bugs (that I have been actively reporting and providing test cases for when possible).

I am not asking for more releases or big QA efforts, I am asking for a single new stable release that AS3 developers can use to work with properly, without having to endure or workaround critical bugs.

Edit: I clarified my first post to reflect that it's an AS3 issue

[gene-pavlovsky]

I would still call it "FlashDevelop", not HaxeDevelop which is basically a special packaging of FlashDevelop.

You are right on one point - the Haxe context basically is an extension of AS3 context.
It might be wise at this point to consider splitting the AS3 and Haxe contexts/plugins. Since AS3 is unlikely to change, there probably wouldn't be many improvements to AS3 features in the future, and making the context/plugin separate it could be made more stable, while allowing more freedom for working on Haxe-related improvements. Opinions? @SlavaRa @Meychi @elsassph @Neverbirth

You would still have to actively report the remaining AS3 issues if you want to have them fixed :)
Or I suppose you could try using some older build in the 5.x series that is more stable for AS3 work, although doing that is a less community-friendly option (but would be understandable if you need to work right now, and the tools are holding you back).

[neuronix]

I don't really think that major technical changes are necessary. The current situation is just related to a rollout issue on the last official release (3 or 4 builds were released back to back due to bugs and quick fixes and still AS3 problems persist). Just scheduling a full round of bug fixing and testing to prepare a new stable release would do the trick.

However, if changes are to be made, and unless there are real technical motivations to split the contexts, I think that the split should rather be in the release management of FlashDevelop vs HaxeDevelop.

Indeed, the contributors are focused on Haxe, and of course, they should be able to iterate and release Haxe updates as often as they wish. But having FD and HD updated at the same time when only the Haxe modifications are being thoroughly tested is introducing bugs on the AS3 side.

Maybe having different release rhythms would allow faster HD iterations, slower FD releases but better testing of the AS3 context before releasing stable FD builds.

[gene-pavlovsky]

The question is what is a "full round of AS3 testing"? Everybody has different workflows and uses different features of the IDE. There is no test plan covering all of the features in all combinations, and if there was, it would take probably man-weeks to perform those tests.

So in my opinion the only way to actually find new bugs is to release often and let the users report the problems. You might feel this is not nice but I have no idea how else it could work.

As for your proposal, imagine there is a full round of fixing the already reported AS3 bugs, followed by a new "stable" FD release. Then there is a long time without a release, just imagine how many more bugs would be found with a new version. Agile software development always considers it's better to release often.

I will mention once again - FD is not focused on Flash (yes it's historically called FlashDevelop), it's a do-it-all tool. HD is the Haxe-specific version. The Haxe devs I know that originally come from Flash, all use FlashDevelop, not HaxeDevelop. They wouldn't like it very much if FlashDevelop stops getting updates and they would have to switch to HaxeDevelop.

[neuronix]

You are probably right, the frustration is coming from having to rely on development builds in order to fix critical bugs in the previous release build that then introduce other bugs. We'd just need a new stable release that we can rely on.

[gene-pavlovsky]

If there's such a thing as a stable release :)

[neuronix]

Just bumping this topic since it's still relevant 2 years later :/

[matrix3d]

100 bugs every day!
#2981 (comment)

[Meychi]

The project doesn't have active maintainers anymore, we have moved on to other things, i just keep the basics running so that it's still online. We welcome new active developers to take over the project. The other route is to ditch the project and just have the repository available.

Any takers?

[matrix3d]

Although there are many fd bugs now. But first because of habit problems, and in free software, it still supports the best IDE for as3. Especially ctrl + shift + 1 works very well. So that's it. It is estimated that the development time of as3 should not be too much.

[SlavaRa]

@Meychi i'm here ;)

[gene-pavlovsky]

@neuronix What is wrong with using an older release which you deem to be stable with regards to AS3 support? Were there any amazing new features added since then that you want to have?
It seems that @SlavaRa is the only guy still taking care of FlashDevelop, and AFAIK he only uses it for Haxe development - so you can guess how much motivation is there for doing something on the AS3 front. You could try starting to debug the issues you're having yourself, maybe? That's what I did soon after I started filing FlashDevelop bug reports some years ago. C# is quite easy to understand and FlashDevelop's code is not that hard to read.