The upcoming official Habari addons directory will be using a post-receive
hook on Github repositories, and we'd like to use tagging to identify
released versions of plugins and themes, such that an 0.8-1.0 version of a
particular plugin (denoting that it is version 1.0 of the plugin for Habari
0.8.x) would be available, and identified as such.

Despite having some experience now with moving code around using git and
Github, I haven't gotten the hang of tagging so much yet. The existing
post-receive hook code (http://github.com/mikelietz/post_receive) is able
to identify a tagged commit, but in testing (often by hitting the 'test
hook' button rather than pushing commits) I haven't really seen how/when a
tag comes across.

Also, it seems the default is to not push tags to the remote repository at
all.

These are just things I've seen, and may not be representative of how
tagging works in the real world. Anybody have good experience with tagging
and could shed some light on a possible best practice?

mikelietz

One quick question: do we really need to have the Habari version in the
tag?  This will unnecessarily result in many duplicates of the same plugin
with the only difference being the tag.  This will also potentially lead to
an administrative nightmare and confusion with users.

I know why there is the desire for this, but maybe we should make this an
exception rather than the norm.  Or maybe extend plugins to include a
"compatible" or "min/max version" option in the xml file?  You're already
parsing the file, so one or two more fields to check won't be the end of
the world.

Now for your question...

I've not had much experience in using tags, but I know they're way more
complicated than on SVN and are not pushed by default (as you pointed out).
 I've only used simple tags (ie no annotations, messages, signing etc) and
haven't had many problems with it.  Using them simply seems to keep things
a bit like SVN, but I'm not sure to what extent.

Hopefully someone else with more production use of tags will chime in too.

We would like it if, when you created a tag in a Github repo for a
plugin, that action would cause the addons directory to display the tag
as a new version of your plugin for download.

I think the difficulty is in identifying a workflow that would
appropriately trigger the code in the addons directory to produce this
listing.

Owen

0.x-1.0 - For any Habari 0.x, version 1.0 of the plugin

It's not going to be possible/practical to check whether a plugin that
works in version 0.8 of Habari continues to work as expected in version
0.9.

I suggest that instead of including explicit version numbers for plugins
that requires specific versions of Habari, we include that as part of
the <requires> data in the plugin info.  As part of Habari 0.9, we can
include a general <provides>core-0.9</provides> in core, and plugins
that require 0.9 and include a <requires>core-0.9</requires> in their
info, which will appear in the addons database.  The Habari version of
the plugin will remain 0.x.

Consider an example:

The Coffee plugin releases a version 1.0 for Habari 0.8.  The tagged
version is 0.x-0.8.  It does not require any specific feature of Habari
that is not available as of the plugin release, so no <requires>
elements exist in the plugin xml.

At some point, we release Habari 0.9.  The Coffee plugin continues to
work with 0.9 just fine.  No changes are required, since the tagged
version of the plugin is 0.x-1.0.

The Coffe plugin then adds a feature that requires a feature of Habari
0.9.  A new version of the Coffee plugin is tagged 0.x-1.1 and the
requirements in the xml are updated to:

  <requires><feature>core-0.9</feature></requires>

On the addons directory, version 1.0 of the plugin and 1.1 of the plugin
are still available (though 1.0 may be hidden behind a "show all
versions" link), and both indicate a 0.x version of Habari.  But version
1.1 will indicate an additional requirement of "core-0.9", and won't be
able to be activated under Habari 0.8.

When we reach 1.0, this will become less relevant, since we will not
change API features within minor version numbers.

Comments? Other suggestions?  I have some additional thoughts of my own,
but I'll wait and see if anyone finds this useful.

Owen

In that case, this seems like a more sensible method of tagging than trying
to keep up with each pre 1.0 release.

+1 to the system and adding the <requires> to .9

I agree.  I like this idea. I was thinking along these lines.