Symphony.

Database updates — it seems Alistair had considered this, but may have been lost in communicado:

http://github.com/symphony/symphony-2/issues/unreads#issue/1/comment/10089

The update.php should really handle the whole procedure without manual intervention.

I agree with #2 — I installed 2.0.3 on my train journey to work and discoverd 4 or 5 bugs straight away. I’ve patched them up this morning, but will it need to wait until 2.0.4 for these to be integrated?

A small cooling-off period before public launch would have mitigated this.

That, or very rapid point-releases, so that a week later 2.0.4 can be released with additional bug fixes.

jQuery does this well. In the past they have released a version, bugs have been spotted straight away, and a new version released within days or weeks, with a new version number.

That, or very rapid point-releases, so that a week later 2.0.4 can be released with additional bug fixes.

That is indeed the plan.

That, or very rapid point-releases, so that a week later 2.0.4 can be released with additional bug fixes.

That is indeed the plan.

I for one would prefer release candidates. :-)

Ignore me. This forum needs a delete-button :-)

Release candidates work well for major-point releases: 2.0, 2.1, 3.0 etc. But creating an entire RC for a minor-point may be counter-productive.

The flurry of updates just before the release of 2.0.3 look like they were merging of Rowan and Allen’s integration branches, and making rapid amends to readme/install/update scripts (which take a fair bit of maintenance I imagine).

Many of the bugs ticked off have been in the integration branch for many weeks — I know I’ve been sending patches over the last few months.

Perhaps a few days’ grace once a minor-point is ready. A message could go onto the forum inviting people to try it out and submit any obvious bugs they can still see.

A more frequent release schedule would allow these bugs to be fixed and released consistently rather than one massive release of many bugs every few months.

Is there any way we can help to streamline the release procedure?

We felt that we needed to push 2.0.3 out the door since it was becoming a monstrosity and stretching the definition of a “minor point release”.

Currently the release process is very involved and also quite error prone.

We’re working on the goal of making minor point releases quick (weeks, not months) and offer release candidates for major point releases.

We have plans to overhaul the update/install/workspace system so it’s both easier to for us to make releases and make the updating process more streamlined.

Symphony 2 also marks our first time working with the community on system improvements via the integration branch. We’re making mistakes and learning at the same time – I feel we’ve just begun to embark on our journey into open source, having been living under a predominantly closed development environment for 4 of the 5 years that Symphony have been around.

Pull requests and minor point releases will become more frequent. Communication between update plans will also be more transparent.

Allen: Sounds good.

And please don’t get me wrong on my “do this”, “I want that” or “why not change this?”.

I absolutely love what you have produced so far. Unfortunately, the only way I can try to help you guys so far is by letting you know what problems I am facing or what improvements I have in mind.

Ok, just updated to 2.0.3 and 2 things.

1. It said do you want to update from 2.0.2 to 2.0.2
2. My Publish menu is lacking the word Publish, it’s just a blank space.

Also, why remove the template part of the form? Seems to be an extra few clicks to be able to get to the template section.

Just wondering.

My Publish menu is lacking the word Publish, it’s just a blank space.

Read the upgrade instructions (need to run SQL querys).

I read the Updating part.

So I need to do this too?

Adding Navigation Group to sections

Ok.

This part:

#### Update Upload Field

 Update your corresponding entries_data_xx table with the following:

ALTER TABLE `sym_entries_data_XX` CHANGE `mimetype` `mimetype` VARCHAR( 50 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL

 The table number, 'XX' should be whatever ID of your upload field. If you have more than one upload field,       run the above query for each field.

I don’t have any sym_entries_data_XX

I do have sym_entries_data_XX but there are loads of them - over a hundred.

XX refers to an id that is an upload field. You look into the sym_fields_upload table to find those IDs.

Seems to be a little bit of a pain. Is there any reason why this is? Don’t ever remember having to do it before.

Also in comment 33 I put in sym_entries_data_XX as that is what it says in the readme. But it automatically converted to sym_entries_data_XX -

What happened there?

The update.php should really handle the whole procedure without manual intervention.

I went ahead and modified the update.php script to execute these queries itself so that the developer does not need to:

Lines 88–100:
http://github.com/nickdunn/symphony-2/blob/bb08bf21225b99bc3e08ec2b4f2253ca09177734/update.php

Note: while I have sent a pull request to the team, this isn’t an officially approved patch. I’ve tried it locally on a test build and it seemed to work without issue but you may wish for it to be officially supported.

Good stuff mate.

I actually now like the separation between the Page Options and actual Template, however - I think it would be better if we could have a link straight from the Page Options screen to the actual template.

What do you think?

That could work — how do you think it would look?