Git(hub) tagging

[mikelietz]

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

[Colin]

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.

mikelietz

--
To post to this group, send email to habar...@googlegroups.com
To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-dev

--
Colin Seymour
Blog: http://colinseymour.co.uk
Tech Stuff: http://lildude.co.uk
Barefoot Running: http://barefootrunner.co.uk
IRC: lildude #habari

[Owen Winkler]

On 6/13/2012 9:55 AM, mikelietz wrote:
>
> 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?

Put a different way:

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

[Owen Winkler]

On 6/13/2012 10:48 AM, Colin wrote:
> One quick question: do we really need to have the Habari version in the
> tag?

Since our API is meant to change only at major version numbers, I
propose plugins use versioning like this:

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

[Michael Bishop]

On Wed, Jun 13, 2012 at 11:30 AM, Owen Winkler <epi...@gmail.com> wrote:

.

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.

Just so I understand, did you mean it would be tagged 0.x-1.0 or 0.x-0.8 ?

[Owen Winkler]

Oops, I meant "0.x-1.0". "0.x" is the compatible major Habari version
and "1.0" is the version of the plugin.

Thanks for picking up on that -- I'm glad someone was paying attention. :)

Owen

[Michael Bishop]

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

Owen

--
To post to this group, send email to habar...@googlegroups.com

To unsubscribe from this group, send email to habari-dev-unsubscribe@googlegroups.com

[Colin]

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

To unsubscribe from this group, send email to habari-dev-...@googlegroups.com

For more options, visit this group at http://groups.google.com/group/habari-dev