Allow developers to easily upgrade to the latest git code

[ljm42]

No description provided.

[fisharebest]

Need to consider the 1.4 branch.

If this module is back-ported (the intention), then we must select the 1.4 branch, not the master.

[ljm42]

Would it be better for the admin_site_upgrade.php files on each branch to have their own hard-coded $download_url?

1.4 branch:
  if (WT_VERSION_RELEASE == 'dev') {
    $download_url='https://github.com/fisharebest/webtrees/archive/1.4.zip';
  }
master branch:
  if (WT_VERSION_RELEASE == 'dev') {
    $download_url='https://github.com/fisharebest/webtrees/archive/master.zip';
  }

Or would it be better to keep the files the same between branches and do something like this?

if (WT_VERSION_RELEASE == 'dev') {
  if (version_compare(WT_VERSION, '1.5.0' '<')) {
    $download_url='https://github.com/fisharebest/webtrees/archive/1.4.zip';
  } else {
    $download_url='https://github.com/fisharebest/webtrees/archive/master.zip';  
  }
}

I'm leaning toward the first option, because looking at WT_VERSION is not the same as choosing a branch. Plus, it is the exact same process individual developers would use to specify their personal git repositories.

[fisharebest]

This assumes that once a user has installed a dev version, they will only ever want to install dev versions.

Perhaps a user may wish to install 1.5.3-dev to get early access to a bug-fix, but then wish to upgrade to 1.5.3 (stable) when it is available.

[ljm42]

I hadn't considered that use case, but it is a good one. I think I've got it now.

There are now two paths through the code, one to upgrade to the production release and one to upgrade to the latest dev code.

The production release is offered when:

• fetch_latest_version() returns a higher version than is currently installed
• or if the versions are equal and WT_VERSION_RELEASE=='dev'

The dev release is offered when:

• WT_VERSION_RELEASE=='dev'
• or if the user adds ?src=dev to the url. (I wanted to make it easy for people to switch to dev code, but not too easy)

[JustCarmen]

I think if you do this, you should include a warning. Not everyone is aware of the risks of installing a dev-version on a live production server.

[fisharebest]

The next step needs to be to fix the semantic versioning (semver.org).

In particular, dev releases should have the version "1.5.2-dev" rather than "1.5.2 dev". The former would come before 1.5.2, and the latter would come afterwards.

This would allow the system to realise that 1.5.2 is an upgrde from 1.5.2-dev.

[ljm42]

you should include a warning. Not everyone is aware of the risks of installing a dev-version on a live production server.

This code will only offer you a dev version if you already have it installed or if you manually add ?src=dev to the url, so I don't think there is much risk of people installing it accidentally. But it wouldn't hurt to include a link to the wiki anyway:
http://wiki.webtrees.net/en/GIT

The next step needs to be to fix the semantic versioning (semver.org).

I was wondering if there was a standard we should be following :) I did add extra code to account for this, so it knows that 1.5.2 is an upgrade for 1.5.2 dev, but it would be nicer if we used a format that version_compare() could understand natively.

If you want to change the version nomenclature before accepting this full patch, could I give you a shorter patch that just defines $zip_path_remove rather than hard-coding the top level directory as 'webtrees'? That is the most difficult part of upgrading with a personal git archive. I just saw you changed the version nomenclature already, thanks!

[mnoorenberghe]

I think commit 18a8923 was the result of a merge and shouldn't have been included in the pull request.

[fisharebest]

I'm going to close this, as I don't think this has a place in the core code.

If needed, I think that a custom module could simply set the WT_LATEST_VERSION to point to a custom URL, and then the auto-updater should take over.