Symphony.

All of us love the numerous possibilities provided by Symphony, and all of us have tons of ideas for new features and new extensions.

I recently did some work on Symphony 1.7 websites which I created some hundred years ago. And there was something that really impressed me: No bugs.

What about Symphony 2? Today I tried to update a website which is running on 2.0.3 (including lots of patches) to Symphony 2.0.5, and there are several serious (!) bugs jumping in my way. Indeed there have been many bugs in every new version since 2.0.0. Why? By nature there will be new bugs with every change in concept or features. But do we really need those changes now?

Here is my proposal:

• if we encounter a bug, we should not wait for others to do the work, but post it to the tracker ASAP so it can be fixed soon
• we should concentrate on improving the quality of the core, not extensions nor features

Getting my hands dirty from time to time is not a problem to me. But working with Symphony 2 I hardly ever had clean hands. I would love to see a Symphony 2 version working as stable as 1.7.01 did. And if we want the increasing community to really spread the word, shouldn’t we concentrate on a core system which is:

• small
• flexible
• as bug-free as possible?

This is my two cents. Hit me if I am a fool.

I think we have to find a way to do both.

We do need a very solid and stable product, yes, but at the same time I think we need to continue to encourage the growth and evolution of Symphony. I think most of the community here would agree that the burst of development that’s gone on over the past year has been great, even if it’s introduced some bugs here and there…

But your concerns are good ones, especially for larger-scale sites and clients. You should have a version that feels rock-solid.

So, at the risk of making things more difficult for the development team, I want to float the idea that maybe what we need is a more fine-tuned release system.

Right now, we have major point releases (2.0, 2.1) and minor point releases (2.0.1, 2.0.2). Major point releases are few and far between and contain significant changes and improvements. Minor point releases, if I understand correctly, are intended for smaller scale patches and enhancements. The problem you’re pointing to is that right now minor point release can contain both bug/security fixes and feature changes. This means that every time you want to upgrade to the next minor point release to squash bugs, you’re potentially getting new bugs in return.

Maybe there need to be two separate paths: maybe the minor point releases should contain ONLY critical bug and security fixes, and the goal of the minor point releases is that each should be more stable and secure than the last. This way, for your most important projects you have a solid, reliable upgrade path. All other changes could then go in a development path: maybe as alphas and betas for the next major point release. In this scenario, many of us would still choose to run the development branch (2.1 alpha 1 or 2.0.901 or something like that), but for the most important projects we’d keep them on the minor point releases.

This might actually make the extension compatibility issue a little simpler because you’d be targeting major point releases: anything that works for 2.0 should work, more or less, for the whole 2.0.* series. Rarely should a change be introduced in the minor point releases that breaks an extension. Then, extensions that target the development branch would just be marked compatible with the next major point release.

Edit: Case in point. If I recall correctly, this change to JIT is a fairly recent one. It would, in the system proposed above, have gone into a branch of JIT targeting 2.1 rather than into the version for 2.0.5, which it seems to have broken.

What do you all think?

I think that this is the right way to go, because stability-focused minor point releases will be good for important projects and newcomers alike.

I like the clarity of

minor point = fixes your bugs

major point = gives you new features

I also like how this would allow for a minor point bug-fix path after a subsequent major-point release. So if I have a site I’m keeping on 2.0.4 (for extension compatibility or whatever), I can submit and receive bug fixes even after the latest major-point release has moved on.

minor point = fixes your bugs

major point = gives you new features

Also, ideally that way you won’t have to check if your extensions still work every time there is a minor point release. Sounds good to me.

Another idea:

• mini release = bugfixes
• minor release = new features, improvements, bugfixes
• major release = backwards compatibility breaks, new features, improvements, bugfixes, …

And the versioning: (major release).(minor release).(patch level)

@phogue:

Also, ideally that way you won’t have to check if your extensions still work every time there is a minor point release. Sounds good to me.

That’ a good point!

I have managed to update the website I mentioned, and now I am improving the inner structure and adding features. You can not oversee that Symphony has become much better with the last minor-point releases, and that it has got some new killer features as well (like navigation groups).

So I think that czheng is completely right.

So I think that czheng is completely right.

Might be the first time I’ve ever heard that. Now I just have to get my wife to read this thread ;)

Yup. :-)

I’m all for this as well — it’s one of my colleague’s (rwarrender) frustrations — new functionality being added to a minor point release.

@michael-e: this might be best served as another thread but it would be useful to know specifically what bugs you came across, or what functionality in Symphony 2 gives the impression that it is buggy. Were most of these related to Extension incompatibilities?

As an extension developer I find it impossible to test every extension on each new version of Symphony. Having to test 10+ extensions on every new minor version isn’t something I should have to do. And breaking an implementation gives the impression that Symphony is buggy, whereas it is actually the extension that is buggy.

I’m also of the opinion that if an extension requires a modification to Symphony’s core for it to work (e.g. Rowan’s Email Templates Filter requires a change to class.frontendpage.php then the extension should be flagged as Unstable or Beta until the changes they require are merged into the core.

Having known versions distinguishing bugs and features should make some form of extension compatibility check a more possible reality.

It would certainly be useful to have bugs associated with specific releases on the issue tracker.

@nickdunn:

Were most of these related to Extension incompatibilities?

No, most of them were in the core or in “core extensions” (like the JIT broken bug). I would never have started this thread like I did if it was about third party extensions… Generally I am rather precatious when it comes to extensions. I try to get an impression of how it is done and how future-proof it may be before I really use it on a live website.

All the bugs I found are recorded. I always try and post bugs on the bug tracker immediately – one of my intentions with this thread was to encourage everybody to do so. It’s best when it’s fresh.