Symphony.

I was very happy this morning when I saw that Symphony 2.0.7 just had been released as this update fixes a lot of small but annoying bugs of the previous version. So this is great news and a big thank you goes to the Symphony team and all contributors.

But …

There always seems to be a problem when new versions are released: those of us trying to follow the changes in the core integration branch and the changes in the core extensions don’t know when a release date is scheduled. There are some signs though: normally it gets silent on GitHub for a while followed by a bunch of updates at once and a release soon after. Usually I just started testing the latest changes when I see the release message and usually I still find small bugs afterwards that should have been fixed before the release. This results in fixes sent in shortly after a release of a new Symphony version which will not be usable for other users until the next version will be release.

I’ve asked this a lot of times: Why don’t we have release candidates for Symphony?

Let’s say a week for testing and bug fixing. No more feature additions besides things that should be done when the code is considered stable (like localisation improvements and corrections). We’re all spread over the globe: I am – for example – half a day behind in time in relation to the core team, so it takes time until you see changes and find the time to test these. The current coordination of code contributions from outside the team is in need of improvement. And this is not just a problem of the Symphony core, the core extensions are also affected.

If there is no official test phase we don’t have a forum to highlight and discuss issues that should be fixed before the next release. The current state of the issue tracker which does not show new entries or replies and which just hides closed issues is not usable as a discussion platform for these things.

I don’t want to offend anyone. I know we are all passionate Symphony users and contributors and things have been greatly improved with the redesign and restructuring of this site. But I think core contributions and release coordination are essential for an open source project and I’m just not happy with the current state of affairs. If you think I’m wrong, please tell me! I just think this topic has to be discussed.

I share your concerns Nils. I know there are a couple of updates in 2.0.7 which break backwards compatibility which have knock-on effects both for existing projects to be upgraded and extensions that rely on things staying the same.

I’m talking specifically about changes to the Event XML output. There was no mention or warning in the release. While this will undoubtedly frustrate upgraders, it also means my Form Controls (and other utilities) are out of date. An early RC of 2.0.7 would provide a grace period for people to release new versions to remain compatible.

(Although my peeve is that we shouldn’t need to, minor releases like this shouldn’t break compatibility anyway).

There were so many updates between 2.0.6 and 2.0.7 that it becomes almost impossible to check them all against extensions. A few releases back there was an air of “release early, and release often” which meant the differences between versions were less, making it more manageable to keep track of what has changed.

It would be useful to have an accompanying list of “might break” issues, or known changes that will break backwards compatibility. As an extension developer I find the “spot the difference” game with each release rather daunting.

This might be a small typo, but in the release history I spot two strange points:

• Changed the ‘post-value’ element in XML events to ‘request’.
• ‘request’ element renamed to ‘post-values’, and XML structure reverted to address backwards compatibility concerns.

I agree with Nils and Nick. Especially:

• Breaking compatibility in a minor point release (e.g. by changing the Event XML output) is not funny at all.
• Extension developers should have the opportunity to test with Release Candidates.
• The bug tracker does not show any closed bugs (which would be good to test the fixes).
• There are too many open bugs.

I was still hoping that Symphony 2 would reach a “mature” state again (which we once had with version 1.7.01 – it was simply working as advertised). At the moment we have some ghosts flying around (like v2.1, v3), plus a brand-new minor release which will cause upgrade pain (and still has too many bugs).

Do you remember the “membership growth” graph on the old Symphony website? I do. It showed that community growth has slowed down significantly since the release of Symphony 2. Shouldn’t it be the other way round? (I still love Symphony, that’s why I need to say this.)

I really hope that the core team will address some of the mentioned concerns.

I was still hoping that Symphony 2 would reach a “mature” state again (which we once had with version 1.7.01 – it was simply working as advertised). At the moment we have some ghosts flying around (like v2.1, v3), plus a brand-new minor release which will cause update pain (and still has too many bugs).

I totally agree but the problem lies in this sentence in the release notes which clearly states that 2.0 will never reach that point of stability:

Version 2.0.7 is our last minor point release before moving to the version 2.1 development. This is primarily a stability release which adds new delegates and fixes a long list of bugs.

It seems like 2.0.7 is considered feature complete (which is just fine) and stable (which it is not in my opinion). It would be good to really clean up version 2.0 before moving to 2.1 while giving extensions developers and core contributors time to test version 2.0 for bugs in a given time range. This is a question of communication and project management (my two cents).

Version 2.0.7 is our last minor point release before moving to the version 2.1 development.

A friend of mine once called Symphony 2 a “moving target”.

Some the team are still on holidays, but once we’re back in full-swing, we’ll address this issue in full.

All the concerns are well noted and it is something we will do our best to resolve in 2010. Please be assured that version 2.1 will have a proper development and release cycle (beta, release candidate, then final) and will be provided to developers well ahead of the final release date for compatibility and stability QA.

As mentioned on a different thread, we’ll look at a 2.0.8 release to address any outstanding issues before forging ahead with 2.1.

We’re still learning how to better manage our system post our 1.7 closed-source era. Let this be our 2010 new year resolution.

I don’t need to say anymore, just want to support what Nils and Nick said. Thank you for bringing this up!

First of all: happy New Year everyone!
Secondly: thanks Allen for your short statement.

I’d like to use this thread to highlight a few things that I think should be fixed in or added to the 2.0.x branch to have a stable, working and consistent Symphony version that is future-proof besides an upcoming version 2.1. It would be great if others could add their issues so that we could discuss these. I think we then need two deadlines: One for our patches and another for final testing (e. g. end of January for the first and a week later for the latter).

Issues with Localisation

1. The core Symphony files and especially the core extensions are still missing a few strings for translations. This has been posted on the issue tracker and there are some pull requests on GitHub.
2. Currently the distribution of language files is inconsistent: while the select_box_link offers a lang folder with German translations the other core extensions do not. The Symphony core does not offer any languages besides English. In my opinion at least all core extensions should contain their own language files (we currently have Brazilian Portuguese, Dutch, German, Italian and Russian) as these only contain a few strings and this is the place the translations strings belong. Concerning the Symphony core it would be desirable to either have the files integrated in the download package as well or have a list of available files in the readme linking to the related repositories.
3. A missing feature when talking about localisation is language selection: Symphony currently does not allow to set languages either system wide or on a per user base. Localisation Manager tries to solve this problem but the implementation is hackish and not stable. In my opinion this is something Symphony has to offer out of the box: if there is more than one language available to the system, it should automatically add a selection to the preference pane and to the author profiles. If there is no option for language selection in the core distribution we shouldn’t release language files at all.
4. I mentioned this idea months ago in a thread but can’t find it anymore: it would be nice if Symphony either completely replaces the current use of the date() function with strftime() or at least uses the latter for the backend display of dates. This way the backend would be completely translatable.
5. The data source editor needs to be tested extensively with different language setups as there seem to be some logic bugs with translations in the editor behaviour.
6. There seems to be an issue with translations on the front-end (this affects the maintenance mode).
7. All localisation files should be proof-read.

Data Sources

1. External data sources do not properly allow the usage of parameters like {$root} or {$workspace}. This is an annoying bug that should be fixed.

Internet Explorer support

1. There are some outstanding issues with styles in Internet Explorer that should be fixed.

Even if this list contains a few feature request I think all mentioned issues should be addressed in the 2.0 branch.

Move from 2.0.7 to 2.1 would be a big mistake. As Nils said, All these issues should be fixed on 2.0 branch until being really stable.

Thanks to Symphony team and all contributors. Happy new year!

I think the intention was that 2.0.7 would indeed solve these issues, clearing the way for 2.1. From 2.0.3 the focus has been on stability and performance, which is backed up by the 300-odd bug fixes (note: not new features, these are fixes). I’ve got a blog post coming that discusses some amazing performance optimisations in 2.0.7.

It would be nice for a 2.1 release to be features only without having to worry about bug fixes. Therefore it makes sense for a 2.0.8 and dare I say it a 2.0.9 to really nail the remaining items.

I have an additional request; the team needs to query the database to find users with extensions and communicate releases and promote extension compatibility.

The success of each version is only as successful as the available extensions (core or not) for that version.

I have an additional request; the team needs to query the database to find users with extensions and communicate releases and promote extension compatibility.

Seconded; that would be the bomb diggity.

How about scheduled releases with designated testing periods, and a development timeline on the website?