@mattab opened this issue on August 11th 2015

The goal of this issue is to give Piwik administrators the ability to choose which Piwik major version they want to use. ## Current Update Settings

## Proposed changes to Piwik core - When a user selects "Use the latest beta release = Yes" then.... - the very latest beta release will be used - (no change to this behavior) - When a user selects "Use the latest beta release = No" then.... - Add a new label "Use the latest release" with two radio buttons: - [ ] Yes (recommended, Piwik 3.0.0) - [ ] No (use Long Term Support version, Piwik 2.15.1) ## Changes to api.piwik.org service - the https://api.piwik.org/1.0/getLatestVersion/ service needs to be updated to know whether a given Piwik user is on the LTS channel or not - Add a new parameter eg. lts=1 or use_lts=1 - when lts=1, return the last 2.X version - when lts=0, return the latest stable release

(fyi: I can make those changes to api.piwik.org whoever works on this please let me know) ## Notes - high value to user: from the UI one can choose to use auto-update to the bleeding edge (beta), the latest stable release (3.X) or the Long Term Support version. - This is a change we should make in Piwik 2.15.0 as users need to be able to use the LTS version - LTS is announced in https://github.com/piwik/piwik/issues/8546 - the UI and feature should be designed to auomatically work when we next release Piwik 4.0, Piwik 5.0, etc. ideally we wouldn't need to change anything in Piwik core.

@mattab commented on August 11th 2015
  • In the Upgrade notification box, to expose this feature clearly, we should tell users that they can choose LTS or latest release in the settings. TBD how
@thomaszbz commented on August 11th 2015

Would you please default to LTS for existing 2.x users when they do nothing at all (no selection)? Basically that would mean that users should actively opt-in for 3.0 if they want to. Same for 4.0, 5.0, ...

The reason for that would be that they can easily upgrade to the newer version but downgrading to a LTS release could potentially be painful (schema changes in database etc.). Plus, dependencies for the new version might not be fulfilled.

There should also be a dependency check for the newer version (PHP version etc.).

@mattab commented on August 12th 2015

Would you please default to LTS for existing 2.x users when they do nothing at all (no selection)? Basically that would mean that users should actively opt-in for 3.0 if they want to. Same for 4.0, 5.0, ...

For us making Piwik it is very helpful when more users are on the latest version.

Maybe we should not let user update to the latest version and stay instead on LTS, when one or more plugin currently in use are not yet compatible with the latest version. Maybe we could detect this and let users know which plugins are not yet compatible with latest Piwik (looking on Marketplace for available updates, and listing there also any private/other third party plugin)

in your opinion, why should we default to LTS?

@thomaszbz commented on August 12th 2015

in your opinion, why should we default to LTS?

Because a downgrade back to LTS could be painful: Or can you make sure that database schema downgrades will be working (for years!) without the loss of data?

If you want to default to the new version, users should make at least an explicit choice before they leave LTS.

Personally, using Debian 8, I will go for 3.0.0 as for me there's no reason to stay on Piwik LTS.

@MagicFab commented on August 12th 2015

Here are two screenshots on how Debian lets users choose.

Ubuntu has more elaborate conditions about this, IIRC.

@MagicFab commented on August 12th 2015

In the same dialogs in Ubuntu the main difference is the mention of LTS versions notifications:

@MagicFab commented on August 26th 2015

The OwnCloud project recently introduced release channels to let its users manage stable/LTS vs. other versions in use. This could refine the LTS implementation in Piwik.

@tsteur commented on August 31st 2015

Will there be no beta versions for 2.X?

I like the term "release channel". Will use that one

@tsteur commented on August 31st 2015

I started working on it and after using a switch statement I noticed it will make sense to introduce "Release Channel" classes. So CoreUpdate or CoreAdminHome plugin will be able to provide a list of available release channels. To introduce a new release channel we will probably only need to create a new class. In theory we could allow people to introduce custom release channels but not needed for now I reckon. Could be useful to maintain updates for clients etc. where a custom build is built on a central server etc.

Currently looks like this but it is to be defined whether we will have beta versions for 2.X.

I won't implement the proposed "When a user selects "Use the latest beta release = No" then...." thing as the UI will be generated depending on the release classes I reckon.

I moved the config entry to [Debug]allow_upgrades_to_beta=0/1 to [General]release_channel=latest_beta|latest_stable|latest_2x_stable|latest_2x_beta. Just using lts=0/1 won't work as we will maybe have 2X LTS and 3X LTS at the same time etc. This will allow us to add 3x_stable, 3x_beta etc.

Changes to api.piwik.org service

I will send a additional URL parameter release_channel=(latest_beta|latest_stable|latest_2x_stable|latest_2x_beta)

Currently api.piwik.org only returns a stable version, it would be nice if it did also return the latest version for beta version(s). Currently, http://builds.piwik.org/LATEST_BETA is used to get the latest beta version meaning they don't connect to api.piwik.org. If there will be 2.X beta versions I'd need either http://builds.piwik.org/LATEST_2X_BETA or api.piwik.org to handle all the version checks as suggested.

What I need to know as well is under which URL the builds will be available. For example:

    const LATEST_VERSION_URL = '://builds.piwik.org/piwik.zip';
    const LATEST_BETA_VERSION_URL = '://builds.piwik.org/piwik-%s.zip';
    const LATEST_2X_VERSION_URL = '://builds.piwik.org/piwik2x.zip';
    const LATEST_2X_BETA_VERSION_URL = '://builds.piwik.org/piwik2x-%s.zip';

So what I need to know for now: - Will there be beta versions for 2.X? - Under which URLs can I check for 2.X beta versions if they exist? - Under which URLs will the builds be available?

What @mattab needs to implement in api.piwik.org - Recognize the release_channel URL parameter and return correct version based on the URL parameter.

@mattab commented on September 1st 2015

Will there be beta versions for 2.X?

yes

Under which URLs can I check for 2.X beta versions if they exist?

Ok, we can move the logic from http://builds.piwik.org/LATEST_BETA to api.piwik.org - I can make the change.

Under which URLs will the builds be available?

let's keep current URL structure http://builds.piwik.org/piwik-X.Y.0-bZ.zip

The screenshot above looks promising :+1:

@tsteur commented on September 1st 2015

Sweet, thx. If you want to test it already @mattab , check out https://github.com/piwik/piwik/pull/8688

I just noticed we need to maybe hide or disable certain release channels if requirements are not met, eg because of PHP version. So far it's maybe not a problem yet as Piwik 2.X should run on all servers and if someone selects latest stable with PHP 5.3 we would just fallback to Piwik 2.X via api.piwik.org. Or should we disable that option in case conditions are not met (and on hover show a title "please update to PHP 5.X to activate this channel")? I kinda like the thought of being able to change requirements in api.piwik.org at any time and not having it defined in Piwik and api.piwik.org. If we ever change requirements older versions of Piwik won't notice that change as it would be hard coded in Piwik.

I tend to not handle these kinda things right now and just always show all options but up to you.

@MagicFab commented on September 2nd 2015

Instead of hiding, disabling by showing them in gray and linking to the system req's check could be helpful. then in System Check such channels being disabled/unavailable could be highlighted (related to #8700 ?).

@tsteur commented on September 4th 2015

I worked a little on it but noticed it's not that easy and we'd kinda need an API on api.piwik.org for this. I could kinda identify whether a release channel is available or not but I would not be able to explain why it is not available since requirements are specified on api.piwik.org. I will create a new issue for this

@tsteur commented on September 4th 2015

created https://github.com/piwik/piwik/issues/8710

This issue was closed on October 2nd 2015
Powered by GitHub Issue Mirror