Symphony.

Hi to all,

Once again, I must say that I did some research on the website (in the extension and forum sections) about this and could not find anything on this subject.

For us, updating all our production website usign Symphony as become a pain in the ass. We though about usign git, but we are often on Centos (lack of proper git support). We also work with shared server (no ssh access). We would also like non-technical people to be able to update the core.

So we though of coding a Symphony Updater Extension....

Its primary feature would be to: -Download the .zip from github -Copy the files -Redirect to update script

I can see a lot more things to add to this -Updating extensions too! -Trac the tags from git hub and permit updating to them -Link to ext to the dashboard

We would like to know if 1- It's interesting for you 2- You want to contribute to this 3- Have any thoughts/hints

Thanks!

I think this has been discussed a long time ago (18 months+) and the main concern was a 'one touch' updater can potentially break an entire site if the extensions don't have equivalent updates (or you have custom datasources/events). This would mean that you'd have to snapshot the install so if anything went bad, it would be revertible (possible, but there's always an element of risk :))

Symphony 2.3 introduces new extension.meta.xml files for extensions that would possibly allow an extension (or the core in the future?) to notify a user that there is an update available for an extension, but it's early days yet :)

We would also like non-technical people to be able to update the core.

Woah. Why?

This would mean that you'd have to snapshot the install

Or: do it the proper way and setup a test / acceptance environment on which you can safely try out the upgrade before going live.

Hey! Thanks for your replies!

@brendo: This was one of my concerns too... And we would absolutely need a Rollback process...

I have been following the extension.meta.xml discussion and this sounds great :) We would only need the git hub repro url !

@nickdunn: Because we often deal with stakeholders that deal with a third party IT team. 90% of the time, and even if the call themselves IT specialists, they are not able to update Symphony on their own. I know it's not the best practice, but sometimes we need to do bad moves in order to satisfy the customer.

@remie: You are right... but this is not always possible! I think the rollback feature could be great! And we could link with the Maintenance Mode...

@everbody: Do you think the community needs this ? Or I should spend my time on something more usefull for all of you ?

I would not be using this extension, but I can image it would make a lot of people happy! Just be careful not to spent to much time on it, it sounds complex :)

but I can image it would make a lot of people happy!

this is what I think too... but I would like to know if this is the case!

I can see it being great when it works, but horrible when it doesn't.

If we use the upcoming 2.3 release as an example, you definitely would not want a client to just go 'Update' on a 2.2.x install (or worse 2.1.x) and think they'll be in happy waters. There most likely will be sharks and jellyfish.

Updating between minor versions I think would be relatively safe, it's our responsibility to ensure that there are no breakages between minor releases, but major releases is asking for trouble IMO.

@Brendo: isn't the normal version scheme something like [Major].[Minor].[Revision/Maintenance].[Build]?

So a major release would be going from 2.2.3 to 3.0. A minor release is going from 2.2.3 to 2.3 and a revision would be to go from 2.2.1 to 2.2.3.

Using this scheme, the compatibility claim is valid between revisions and not minor releases?

We work off the [milestone].[major].[minor/point].[hotfix]. So 2 is the milestone, 2.2 is a major release, 2.2.1 is a point release and 2.1.2.1 is a hotfix.

@brendo, @remie: I was planning on limiting the 'auto updates' to only minor/point releases. And the more I think of it, the more I think I would need some global xml file to indicate which updates can be done... maybe hosted on github or some other cdn.

The rollback feature would do the same (permits rollback to only 'some' versions).

BTW, is there a way to reverse the update process already?

the more I think I would need some global xml file to indicate which updates can be done... maybe hosted on github or some other cdn.

I think we need to be carefull not to go to far with META xml files, and even if this would be necessary, it should either go in the release tag / package or, in case of extensions, in the new extension xml meta file.

@remie: Then how would you store the info about which version can be updated to which one ?

That really depends on how far you want to go with this extension... Like I said, ideally, all compatibility information is either stored in the Symphony package, or, for extensions, in the extension META information (XML file / (static) function).

For Symphony releases I would suggest that this information is provided in the core: either in the update script or in some about XML file / class.

@remie: yes but the point is, I want to be able to notify users that a new version is available...

Nick's dashboard extension give you the most recent version releases, I am going to check how he did it.

Nick's dashboard extension give you the most recent version releases, I am going to check how he did it.

Badly. I read the list of repo tags from Github and sort them, then I take the newest one. Ideally the Symphony website would have an API for this directly.

Ah right, now I get it... I have the same requirement for the Symphony Developer Network website I'm working on. Like Nick, I was planning on using the Tag list from Git after having established that there is no point in parsing the releases section or using the feed.

It would be great if the Symphony website would offer XML / JSON list of releases and their repo location. Same goes for the available extensions BTW.

Yeah, this is what I was meant by:

would need some global xml file to indicate which updates can be done... maybe hosted on github or some other cdn.

Basicly, a service that offers this data to anybody :)

would need some global xml file to indicate which updates can be done... maybe hosted on github or some other cdn.

This is planned for the new Symphony website. We used to have this actually, but was taken out just before 2.0 was released (years ago). The main concern was privacy related as calling "back-to-base" was not optional and was done at every page load.

The plan for the new website is to have publicly accessible release history for core and extensions, where sites can choose to pull data from.

@allen: Great news !