Check plugin compatibility before upgrading

Gocom · 2013-05-02 10:15:13

philwareham wrote:

So I guess that pulls the theme directly from my GitHub repo yes?

Yes, Composer uses source repositories to get the package code, which removes any need for manual packaging. Supports git, svn, hg.

In that case I need to manage my repo better, as I’m just working away in the master branch at the moment and breaking stuff as I work on it. I’d have to move to working in proper branches and doing tags for releases and suchlike?

Branching isn’t required, but tagging yes. Tags will be announce stable releases, alphas, betas and release candidates. Composer uses semver and detects the tags based on the naming conversion. This also means that releasing becomes super-simple; to release a new version and inform your users, you only need to create a tag to the repository. E.g. if you create a tag named “0.4.1” the tagged rev will be considered as the “v0.4.1”.

Branches on the other hand are not used, other than for development. Branches are considered to contain development code. Users can also use Composer to fetch non-stable dev versions, and you can use (or should) it when developing, but that is up to the user. Composer will use the version the user wants, up to the most up to date version compatible with other package and dependencies. In addition to branches, if you want to mark certain development milestones, you can use semver tags (e.g. 1.0.0.alpha.14).

philwareham · 2013-05-02 10:19:34

OK thanks that makes sense. I’ve placed the composer.json file into my repo, but I need to move all the development code to another branch, put a stable version in master branch and tag it. Might be able to do that at the weekend.

Gocom · 2013-05-03 20:13:35

philwareham wrote:

put a stable version in master branch

Master branch can contain the most latest development code. There is nothing wrong about committing development code to it (not even directly w/o branching), composer actual expects it to contain development code. Your end-user will not be able to fetch it by accident, but only if they explicitly want unstable development code (dictated by minimum-stability property and version constraints).

You can additionally also createaliases for branches, which help users to identify what the branch contains, and help with fetching it with version constraints.

Gocom · 2013-05-03 20:33:15

Latest update to this whole Composer deal makes creating Textpattern version constraints, dependencies and requirements possible. This allows painlessly checking what packages are compatible with the installed Textpattern version. This all works by using a version lock package, a meta package — textpattern/lock.

The textpattern/lock package can be used to lock the installed Textpattern version and handle Textpattern version dependencies in packages. This package makes sure your Textpattern installation and packages are compatible and can work together.

When you start using Composer to manage Textpattern plugins and themes, the first thing you should do is to lock in your Textpattern version. This makes sure the packages you install are compatible with the Textpattern version you have. You can lock in your Textpattern version using the textpattern/lock package and Composer’s require command.

$ composer.phar require "textpattern/lock 4.5.4"

Where 4.5.4 is the version of your Textpattern installation. After running the command any installed themes and plugins are checked if they are intact compatible with v4.5.4. If the requirement can not be met by any version within the constraints, then nothing is installed, and you might have to consider updating Textpattern if there is a newer version available.

The same tactic can be used to check if your existing plugins are compatible with a newer Textpattern version before updating. Just list the dependencies you have, and you will know.

$ composer.phar depends textpattern/lock

You can also try to update the locked version and see;

$ composer.phar update textpattern/lock

The version you get is the most up to date Textpattern version that is compatible with your set of plugins and themes. You can then update your Textpattern installation to that specific version.

Gocom · 2013-05-04 15:12:09

The latest changes have renamed the installer package from rah/textpattern-plugin-installer to more appropriate textpattern/installer. Like the lock package, this is now under the Textpattern vendor.

planeth · 2013-05-13 17:30:06

Hi Jukka,
i tested composer on my local machine .
Got this error message : Failed to clone http://github.com/gocom/textpattern-lock.git, git was not found, check that it is installed …
And yes i am not using git but mercurial …

Gocom · 2013-05-13 22:12:19

planeth wrote:

And yes i am not using git but mercurial

Composer uses version control systems to fetch packages from source repositories. To access a git repository you will need git. This is outlined in the installation instructions.

According to Composer’s documentation, for specifically GitHub Composer can fallback to GitHub’s API, if git isn’t installed and the requested repository and version can be fetched using the API. This means that for GitHub, git isn’t required as long as you have a version contrait that is referencing a tag in the repository, and the repository is public. You getting that message, would suggest that either you are trying to require textpattern/lock without a precise version contraint or you are trying to lock it to 4.6.*-dev.

You may also want to check $ composer.phar help [install|update] and the --prefer-dist flag, which overrides Composer to use dist instead of source where possible.

Last edited by Gocom (2013-05-13 22:13:14)

planeth · 2013-05-14 08:08:16

Thank you for the explanation.
The whole thing is quite new.
Following your explanation i did give a precise version for the require command : failed again.
using —prefer-dist flag : worked

Though it’s not clear what’s the difference between package source and package dist.

Textpattern CMS

Textpattern CMS support forum

#25 2013-05-02 10:15:13

Re: Check plugin compatibility before upgrading

#26 2013-05-02 10:19:34

Re: Check plugin compatibility before upgrading

#27 2013-05-03 20:13:35

Re: Check plugin compatibility before upgrading

#28 2013-05-03 20:33:15

Re: Check plugin compatibility before upgrading

#29 2013-05-04 15:12:09

Re: Check plugin compatibility before upgrading

#30 2013-05-13 17:30:06

Re: Check plugin compatibility before upgrading

#31 2013-05-13 22:12:19

Re: Check plugin compatibility before upgrading

#32 2013-05-14 08:08:16

Re: Check plugin compatibility before upgrading

Board footer