MODX you are not testing enough! MODX 2.3 ThemePackerComponent

Just for the record (appreciate that this may not apply any more Menno):

2.3 was absolutely not released too fast - in fact we should be aiming for release every two months as a minimum.

There was more than sufficient time to test, and there is no obligation to update to a latest branch in release. Plus, it's always recommended that a live site is updated via a stage copy prior to release regardless.

The issue here is actually releases have been far too slow - we've become lazy with solid testing and updating practices. Everyone was so excited to get a release I'm certain it was often implemented too quickly.

If releases are more frequent the sheer desperation to update would be less prevalent.

It's amazing to see such good progress on the MODX project - if we can get some real strategy behind it now we might be on to something.

@DangerMouse,

I think you hit the nail on the head. The sheer anxiety awaiting the release which was long overdue caused an almost panicked need to get onto the stuff we've been talking about since last year. My understanding from talking to @opengeek is to aim for a 8-12 week-ish minor release cycle. With the added integrators and growth in contributions, this will likely be possible. I've even done work on Revo (which I hadn't in years) though I had it committed by someone else for efficiency sake.

There is a reason that the open source model works better, and that M$ is already listing hard to port. If all the bugs could be eliminated, then we wouldn't need a community ;-)

So there has to be a process of finding and fixing stuff, its normal. The problem, for all you yung'uns, is that once upon a time the bugs could be found...but never would be fixed. This model beats that model by a country mile.

But I wonder, is there any sort of ownership of specific components? Here one component wasn't ready for prime time apparently, and it would be nice if a smaller team who rely on that or care more about that could be expected to jump in and fix things. Devolve ownership a bit and let more people get involved.

At the same time, ranting is part of learning new stuff. I jumped on Ubuntu 14.04 early, and regretted it, slagged it off in forums, ranted and raved for a couple months of pure frustration. Swore up and down I would never jump in on a new release until the first wave of fixing was over.

You know what I figured out? It was faulty hardware the whole time...

I wonder if it would help to have some docs on the how to create unit tests for MODX and some guidelines for doing so. It would be fantastic if we had a real test suite that would: 1) test all or most MODX classes individually, and 2) run a series of tests inside the Manager to make sure that all standard operations can be performed without error.

Then, the suite(s) could be run on all new releases before they go public. Users would get fewer surprises and the core developers could sleep better.

[/PipedreamModeOff]

I know that there are unit tests in the repo at GitHub, but the last time I looked, they were pretty feeble, and I've never been able to get them to run locally.

Unit tests are a very important practice to ensure the core functions as expected. But, again, I do not think they would eliminate all issues related to upgrades where Extras might have worked through sheer coincidence or dumb luck. It's not unheard of for someone to build an Extra and, once they get the desired functionality or output, assume it's working as it should and put it out there. The only way to catch some bugs or new issues is to test in real-world environments.

Unless MODx posts a critical security update, I always defer updating my clients' websites until at least two weeks after an update becomes available. I have a private dedicated server as my playground, and there I will test and develop with the latest releases as they become available.

But I agree that outside of a pure test-driven development or unit testing paradigm, there is no way to anticipate every issue that will arise when major updates are released. What I admire most about MODx, the developers and community and what keeps me a loyal user is that major issues are always addressed without delay. Lest we forget that, unless I am mistaken, core developers invest their time into this framework without any kind of compensation.

Quote from: smashingred at Jul 23, 2014, 07:08 AM

Unit tests are a very important practice to ensure the core functions as expected. But, again, I do not think they would eliminate all issues related to upgrades where Extras might have worked through sheer coincidence or dumb luck.

I don't think I made my point very well. What I was saying was if there were docs and some infrastructure to make it convenient, I would probably write (or rewrite) some unit tests for MODX, and I think others would too.

An added advantage would be that we'd all be running the unit tests on a wide variety of platforms and might catch core issues that are currently not being found until after release.

And speaking of extras, there should really be solid unit tests for the more common Extras like getResources and Wayfinder.

Some of my extras have unit tests (I wish more of them did), and it's a real comfort to run the tests before a new version is released.

Sounds like a very sensible idea Bob; anything to minimise the number of bugs and problems I find with MODx. Like others, I also always have the feeling that versions are released without adequate testing. There always seems to be more effort going into sexy new features than solidifying and strengthening existing but buggy features.

I have been ussing MODx since about version 0.8 or 0.9 and I have spent an inordinate amount of time over the years trying to solve problems. One reason is the release of bugs in the first place. Some are in the core, others are in extras, but they are aall part of modx so all just as important. Another reason is the quality of the documentation: it's huge, different parts of it cover different modx versions to different degrees, it's all written by different people to different qualities and standards, important examples are often omitted and linking between parts of the documentation is poor. In that department I think the open-source model becomes the too-many-cooks model if not properly regulated. And the auto-generated API docs? They can only repel new users.

The last reason is the community. I don't know why but apart from a few dedicated and tireless individuals (Susan, Bob and others) there never seems to be much help out there. Is there a paid version of modx that I don't know about where help is always at hand?.... I'd gladly pay, because it would save me weeks every year.

I hate moaning, but if I don't then user feedback is not going to be accurate, is it? I like modx a lot but it just seems to have become so big and so complex and so unsupported by people or docs when you have problems that it's tiresome. Testing more thoroughly and releasing with fewer bugs would go a long way to help.

I would happily do without new features for a year or two in exchange for a massive effort on bug-fixing and doc-rewriting.

These two items alone would help to encourage new users to adopt modx.

I can be more specific if required

The problem with the docs is that the only way to get the docs you want is to have the whole system re-designed and re-written by a single person, with some help from others.

I don't think anyone is going to take on and finish a job that big with no pay. Everett made a valiant attempt at it, but really, it's not only a huge job, but it's an endless job as well (and largely thankless). No matter how well you do it, most of the feedback you receive will be complaints.