Hello RoundCube-devs!
To update everyone — we've been testing the setup for the plugin repository with a few people and since Sébastien emailed me with a couple questions, I wanted to take it on-list to inform more people.
On Thursday, November 8, 2012 at 6:23 PM, sebastien BLAISOT wrote:
On Thursday, November 8, 2012 at 12:24 AM, Sébastien BLAISOT wrote:
Le 07/11/2012 14:20, till a écrit :
Hey,
sounds good — please head over to http://plugins.roundcube.net, sign up and submit your plugin.
It's a little rough around the edges, but should work.
Thanks for helping!
Hi,
I've created an account but need some extra explanations before
submiting the plugin. How is this plugin repository supposed to work ? does it pull the last
version/revision of trunk ? or can I choose a particular revision ?
A plugin is essentially powered by the composer.json file.
And this is how composer works (in a nutshell):
- it takes the URL of the repository (git, svn, hg)
- it scans all tags and branches (e.g. trunk/master) for
composer.jsonfiles - it will use all tags/branches where it finds a
composer.jsonfile
E.g. (for SVN):
trunk/composer.json branches/super-feature/composer.json tags/1.0.0/composer.json tags/0.9.0/<no composer.json>
The plugin repository would detect:
- dev-trunk
- dev-super-feature
- 1.0.0
So once a composer.json is in trunk, it should get copied with each branch you create from trunk or each time you create a tag.
This process works for git or hg as well.
Will it be automatically updated everytime a commit is made ?
Our current setup is that the cronjobs to update the site are run every 10 minutes. We can crank that up when required.
When the cronjob runs, we scan your repository (see above).
Why are all commits "used"? Because a commit is arbitrary and can mean all of the following:
- updates to a file in trunk
- creating a release (aka tag)
- creating a branch
This is a bit confusing for me right now and I don't want to make a mistake. My need is to control the release of future versions and not having each
commit automatically pushed to users as they are not fully tested at the
time of the commit.
You want your users to use tags and not a trunk/master branch — then not every commit will end up with the user.
Let's say, in my local copy of RoundCube, I add the following to my (!) composer.json:
"require": { "sebastien/plugin": "1.0.0" }
This ensures that I stay on 1.0.0. This assumes that you wouldn't change the tag of course. ;-)
With sane versioning and backward compatibility this shouldn't be an issue. E.g. I personally assume that a point release does not break everything or will require me to do changes that require more changes.
So keeping this in mind, I could do something like:
"require": { "sebastien/plugin": "1.0.*" }
The above allows me to stay up to date with e.g. bug fixes.
If I feel more "bleeding edge", I could rely on a branch (e.g. trunk) as well. But that's up to me/the user.
On top of this, the user's composer uses a composer.lock file as well. This lock ensures what is installed:
http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file
So once I ./composer.phar install'ed a certain version from trunk, the lock ensures I get the same revision every time.
The composer.lock is only updated when I ./composer.phar update.
Perhaps do I need to make a particular branch dedicated to releases ? Or
can it be base on tagged revisions ?
Yes sir — you can actually do both.
I personally prefer tags because it's fixed/done — a branch is always a moving target for me.
Oh, and I'm using svn as source versionning system, not github. is this
an issue ?
So, I personally prefer any kind of git. But composer also supports hg (Mercurial) and Subversion.
Can you please explain it a bit ?
I hope I did with this email! :)
Till
Le 2012-11-08 18:48, till a écrit :
[...SNIP...]
A plugin
is essentially powered by the composer.json file.
And this is how
composer works (in a nutshell):
- it takes the URL of the
repository (git, svn, hg)
- it scans all tags and branches (e.g.
trunk/master) for composer.json files
- it will use all
tags/branches where it finds a composer.json file
E.g. (for
SVN):
trunk/composer.json branches/super-feature/composer.json
tags/1.0.0/composer.json
tags/0.9.0/<no composer.json>
The plugin
repository would detect:
- dev-trunk
- dev-super-feature
1.0.0
[...SNIP...]
Ok, thanks Till for all your explanations. This is far clearer now, at least for me. Last question about this particular piece : what happens if the trunk/composer.json contains the same version than, say, tags/1.0.0/composer.json ? should I ensure that in the whole tree no composer.json file has the same version in it than an other composer.json file ?
regards,
S.B.
On Saturday, November 10, 2012 at 7:19 PM, Sébastien BLAISOT wrote:
Le 2012-11-08 18:48, till a écrit :
[...SNIP...]
A plugin is essentially powered by the
composer.jsonfile. And this is how composer works (in a nutshell): * it takes the URL of the repository (git, svn, hg) * it scans all tags and branches (e.g. trunk/master) forcomposer.jsonfiles * it will use all tags/branches where it finds acomposer.jsonfile E.g. (for SVN): trunk/composer.json branches/super-feature/composer.json tags/1.0.0/composer.json tags/0.9.0/<no composer.json> The plugin repository would detect: * dev-trunk * dev-super-feature * 1.0.0[...SNIP...]
Ok, thanks Till for all your explanations. This is far clearer now, at least for me. Last question about this particular piece :
what happens if the trunk/composer.json contains the same version than, say, tags/1.0.0/composer.json ? should I ensure that in the whole tree no composer.json file has the same version in it than an other composer.json file ?
You don't have to take care of anything in this regard.
The composer.json file does not contain any version specific information. Once setup, it can be the same — unless your plugin's dependencies change over time.
Can you explain in more detail what you're trying to do (or trying to avoid)?
Till
Le 10/11/2012 19:23, till a écrit :
On Saturday, November 10, 2012 at 7:19 PM, Sébastien BLAISOT wrote:
Last question about this particular piece : what happens if the trunk/composer.json contains the same version than, say, tags/1.0.0/composer.json ? should I ensure that in the whole tree no composer.json file has the same version in it than an other composer.json file ?
You don't have to take care of anything in this regard. The
composer.jsonfile does not contain any version specific information. Once setup, it can be the same — unless your plugin's dependencies change over time.
I found on http://getcomposer.org/doc/04-schema.md#version that composer.json package can/should/must contain version information. But I see now that it says : "Optional if the package repository can infer the version from somewhere, such as the VCS tag name in the VCS repository. In that case it is also recommended to omit it." so I will remove the version tag from my composer.json
Can you explain in more detail what you're trying to do (or trying to avoid)?
Well, nothing, now that I've read and understood that composer.json doesn't have to include a version tag ;)
What I wanted to avoid was having two composer.json files in my subversion tree having the same version number. When releasing a new version, when I "svn tag", it leads to having a file in the trunk with the same version number than in the tag an the risk to forget about that.
Nevermind, no more version in composer.json, no more problem.
regards,
S.B.
--
till
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Saturday, November 10, 2012 at 8:24 PM, Sébastien BLAISOT wrote:
Le 10/11/2012 19:23, till a écrit :
On Saturday, November 10, 2012 at 7:19 PM, Sébastien BLAISOT wrote:
Last question about this particular piece : what happens if the
trunk/composer.json contains the same version than, say,
tags/1.0.0/composer.json ? should I ensure that in the whole tree no
composer.json file has the same version in it than an other
composer.json file ?You don't have to take care of anything in this regard. The
composer.jsonfile does not contain any version specific information. Once setup, it can be the same — unless your plugin's dependencies change over time.I found on http://getcomposer.org/doc/04-schema.md#version that
composer.json package can/should/must contain version information. But I see now that it says : "Optional if the package repository can
infer the version from somewhere, such as the VCS tag name in the VCS
repository. In that case it is also recommended to omit it." so I will
remove the version tag from my composer.json
Yeah, just to make sure for everyone:
What they refer to is the version of your package/plugins dependencies.
E.g.
- It could be a specific RoundCube version (or minimum version).
- Or, let's say you require another library to talk to another web server and require a certain version.
- Or a minimum PHP version, etc..
The actual version of your plugin is always based on the branch or tag. :-)
Cheers, Till
Can you explain in more detail what you're trying to do (or trying to avoid)?
Well, nothing, now that I've read and understood that composer.json
doesn't have to include a version tag ;)What I wanted to avoid was having two composer.json files in my
subversion tree having the same version number. When releasing a new version, when I "svn tag", it leads to having a
file in the trunk with the same version number than in the tag an the
risk to forget about that.Nevermind, no more version in composer.json, no more problem.
regards,
S.B. _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net (mailto:dev@lists.roundcube.net) http://lists.roundcube.net/mailman/listinfo/dev
Le 10/11/2012 20:24, Sébastien BLAISOT a écrit :
What I wanted to avoid was having two composer.json files in my subversion tree having the same version number.
Just to let everyone on the list know, I also missed a piece of information :
The composer.json file should reside _*at the top*_ of your package's git/svn/.. repository, and is the way you describe your package to both packagist and composer.
(reference: http://plugins.roundcube.net/about)
so you don't have multiple composer.json files
regards,
-
Sébastien BLAISOT -
till