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