Make the first release and go public

[stof]

Make a command to get notified about new releases of tracked repositories (behat/docs + core extensions)

should it be a command or a webhook relying on github webhooks ?

[everzet]

@stof implementation detail :) Either way should work. Slight challenge with pure webhook implementation is that we'll see documentation and information only for extensions that were updated since system got released. But I think we can live with that at the beginning

[stof]

@everzet all documentation would get built when registering the extension on the site, no ?

The next question is whether we want to force using releases for doc repo. IMO, it makes much more sense to use branches than tags for the doc versions: you don't create a separate documentation for each patch release of your software (a patch version is fixing bugs only, so there is no point having a separate version of the doc IMO), and the doc for a 3.0 release is likely to change after the 3.0 release when users start using it and contributing to the doc.

[stof]

note that I don't know yet how the website actually knows about extensions. I haven't reviewed the code yet (will do now)

[everzet]

@stof the way it currently works is you run this command:

app/console package:released Behat/docs v2.0

where v2.0 is a branch. It fetches the zipball from the GitHub using v2.0 instead of SHA, GitHub handles the rest. This basically means that this command also works out-of-the box with:

app/console package:released Behat/Symfony2Extension v2.0.0

where v2.0.0 is a tag.

Currently app/console package:released only generates documentation for provided version, but after

[ ] Publish information about tracked and released extensions

is implemented, it will also add this particular extension release information to the extensions page.

This basically means that executing this method for particular extension release is all you need to do in order to generate both documentation and extension page for it. Keeping this in mind, the simplest way to implement

[ ] Make a way to get notified about new releases of tracked repositories (behat/docs + core extensions)

is to create a very simple API route that will receive GitHub branch/tag webhook and call that ReleaseManager::release() method for it (performance optimisation in form of adding MQ will probably be required). The limitation of this is as you could imagine, we'll get documentation and extension pages only for releases that we received hooks for, which is as I said fine for the starters :)

Another option is to create a custom release fetcher that for the provided list of GitHub repositories will fetch both branches (ones that look like SemVer) and tags and call ReleaseManager::release() for each one of them automatically. This will cover the problem of previous releases, but at a cost of heavy cron job running every hour or two.

Final-final solution (months after initial release), probably, would be something in between :)

[stof]

This will cover the problem of previous releases, but at a cost of heavy cron job running every hour or two.

I can be done only once a day (or even longer) IMO if we have a webhook in place. Extension authors wanting a faster doc update would just have to register the hook.

[everzet]

@stof when we have webhook in place, we'll need to run this cronjob part once - when extension is first introduced to the borg

[stof]

@everzet should we keep the growing TODO-list in a single issue or rather split it into multiple issues and using a milestone to group them and see the progress ? Having separate issues might make it easier to discuss each topic

[everzet]

Separated into multiple issues of go public milestone