STS and LTS Auto Updates

[Mark Dexter]

Hi folks. When version 3.0 comes out later this year (in September, I believe), some 2.5.x users will want to upgrade to 3.0 to stay on the STS (short term support) track. Other 2.5.x users will want to stay on 2.5 for longer (perhaps until 3.5.0 is released).

At present, the update notification system will notify all 2.5.x users when 3.0 is released and will update them to 3.0.0. So I think we need to fix this to support the LTS track as an option.

To take a specific example, let's say the current release in September is 2.5.4. If a site admin chooses to stay with the STS, they should be notified that 3.0.0 is available (the status quo). If a site wants to stay on 2.5.x releases, they should be notified only when 2.5.5 is released.

I think we should have a global parameter or some other way for site admins to elect the STS or LTS path (perhaps with LTS being the default). Then we need a way in the update system to indicate whether an update is STS or LTS (perhaps an XML attribute in the update XML file?).

Whatever we decide, we need to have it in the 2.5.x version before 3.0 is released. So we should be thinking about this now and get it implemented well before 3.0 is released.

What do people think? What is the best way to do this? Is there a better approach to the problem?

Thanks. Mark

[Ofer Cohen]

+1 for put in the global configuration.

great catch!

Ofer Cohen
Joomlics Anonymous Group

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Ole Ottosen (ot2sen)]

Agree Mark.
It is important to have an electable channel for users to decide which they prefer.

Good that it was caught before the issue arise.

 

Nicolas, as always, already use this in his Admin Tools. Within the config the user decide 'Minimum stability for update notifications'.

 

+1 for having some sort of configurable option in core.

 

Ole

[Geraint Edwards]

Can we also add a 'Check your components. modules and plugins are compatible before applying a version upgrade' message.

Our component was not ready for J2.5 on day one (we had to change dozens of view class names, change the way that template overrides were found and a long list of other minor changes) but we had lots of users who auto-upgraded to 2.5 without checking compatability first and they were left with broken sites.

thanks

Geraint

[elin]

I think we should strive with 3.0 to make it so that there is 0 risk to your site if you move but officially it is a migration not an update.  I think we just want to send the notice that it is available but not even start encouraging people to do it until 3.1 at the earliest. 

Elin

[Mark Dexter]

Hi. I think this issue can be resolved with the new feature we hope to add to improve the auto-update process. Here is a link to the feature tracker issue: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27984.

This feature, as planned, will add a new admin component that will include an option to set the desired update site for Joomla. This means we can set up two core update sites, one for LTS (2.5.x releases) and one for STS updates (3.0.x, 3.1.x, 3.2.x). This also should make it easy for site admins to select alternative update sites, for example to customized distributions for different languages or different extension bundles.

We will keep people advised on the progress of this feature so we can test and get feedback on it. Thanks. Mark

On Mon, Feb 6, 2012 at 5:08 AM, elin <elin....@gmail.com> wrote:

I think we should strive with 3.0 to make it so that there is 0 risk to your site if you move but officially it is a migration not an update.  I think we just want to send the notice that it is available but not even start encouraging people to do it until 3.1 at the earliest. 

Elin

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/kS32ixKTGv4J.

[Geraint Edwards]

Offering the choice is essential but I am making a pitch for  a plain text message that is visible whenever a user chooses a **version** upgrade to tell them to make sure that all their addons are compatible and explaining how to decide which version it appropriate before they proceed.

There are a lot of inexperienced site admins out there who will assume that the latest is the "greatest and best" and will upgrade without stopping to think about the consequences for their live site.  When the upgrade process was not as easy as it is now, they had to do a little background reading first and make a decision of what they wanted to do rather than getting themselves into trouble by clicking a button.

Geraint

[Nils Rückmann]

I'm not familiar with the new installer etc., but if it's not part yet i think we could discuss about a way to add dependencies on the extensions. If somebody would update an extension or joomla itself, the system should tell about failed requirements.

[elin]

Geraint,

I think that  you could just make a patch for that and put it into the tracker.

Elin

[JM Simonet]

There is already a patch proposed including this Notice.

Please test.

See:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=27989

JM

-- 

Please keep the Subject wording in your answers

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the

intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies.

-----------------------------------------------------------

Jean-Marie Simonet  /  infograf768

Joomla Production Working group

Joomla! Translation Coordination Team 

[Beat]

Hi all,

Yes, being able to handle multiple versions is important, not only for
Joomla but also for extensions. So that's a setting that should go
into upgrader, and not global Joomla config.

I have been looking into the auto-updater, and have for now decided
that it is not yet possible for us to use it to do upgrades to
Community Builder suite.

(please correct me if I am wrong):

Show-stoppers identified so far are :

1) There is no filtered HTML information displayed from the site
giving the upgrade information. This is really a key thing. The
information regarding the nature of the upgrade, with html links (not
only displayed URL) for more information on the aspects should be
presentable right in the row showing the upgrade, so that the admin
can make an educated decision before upgrading. Upgrading an extension
with just a click without seeing upgrade notes, and understanding the
consequences of future upgrades seems a bit light.

2) There is no automatic backup before upgrade, or at least a lightbox
asking if backups have been done before upgrading. Sounds stupid, but
it will save dozens of thousands of sites and would move the legal
liability of loosing data or site in a failed upgrade from joomla to
the user.

Annoying but can-live-with-it items include:

3) secure fopen-URL alternatives like curl.

4) There is no standard way to do the installation of the upgrade in
multiple steps. Some slow systems require more than 30 seconds for
large extensions and trigger the PHP-timeout, and thus we need
multiple step support. Single installations is no issue as you are
alone and have HTML output for javascript-driven steps (except for
packages, which do not output any HTML: is that a bug ?). Thus when
upgrading multiple packages same time, one upgrade can interfere with
another.


Point "1)" has to do with giving the user the choice which upgrade
versions paths he chooses, and would be valid for joomla too, that's
why i'm replying here instead of opening a new thread.

Do you agree that the above are issues ? Would Joomla core team accept
pul-requests fixing the issues above (and if yes, what specs ?) ?

Best Regards,
Beat
http://www.joomlapolis.com/

[Sam Moffatt]

Look forwards to your individual patches to the platform fixing each
of these problems and the CMS where relevant to help improve that.

Thanks for volunteering Beat!

Cheers,

Sam Moffatt
http://pasamio.id.au

[Ofer Cohen]

3) check my pull request: https://github.com/joomla/joomla-platform/pull/839

Ofer Cohen
Joomlics Anonymous Group

[Sam Moffatt]

Checked, looks like Rouven got there first though with some
suggestions. I've added some of my own as well.

Cheers,

Sam Moffatt
http://pasamio.id.au