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.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 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 _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
