Habari Extras plugins svn

[Michael Bishop]

I understand the reasoning for doing branches on the recent major
changes to plugins (from the info method to using XML), however, it's
being discussed that we will stop using trunk for the plugins
development, and use branches from here on out.

I'm a giant, -1 on this. Once .7 is released, if not sooner, we
should go back to using the traditional, trunk/branches/tags system.
It makes absolutely zero sense to continue primary development in
branches at that point. We will not be supporting .6 after .7 is
released, so why should we not use trunk? We will have the .6
branches for those who for what ever reason aren't ready to upgrade,
but otherwise, we should go back to the former system.

I know several others have voiced similar concerns in IRC, just wanted
to get this out "publicly".

~miklb

[Michael C. Harris]

Previous thread:
http://groups.google.com/group/habari-dev/browse_frm/thread/53b99ed317f91b64/630774ced1b012e6?lnk=gst&q=extras#630774ced1b012e6

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari

[luke]

Right. Let me prefix my comments with where i'm coming from.

I am a habari user, and plugin writer. I haven't worked on core code,
although i have code dived (diven?). We're basically starting to roll
out habari to most of our clients. It's becoming our software of
choice. That's where we are coming from.

Now. Opinions :)

My feeling on svn is that the three key areas serve fairly unique
purposes:

trunk: Current development. The latest and greatest should be here. If
you use trunk, can can't whine (as loudly) when it breaks, but this is
where the action is. The main purpose is to make the software better
harder faster stronger, and sometimes it will break.

branches: Hey! How about we paint it red! Ideas like this? They should
go in branches. Want to make a change? do it in a branch.
Additionally, in this situation, we still want to be able to maintain
development of a plugin for a prior release. Do it in a branch. Want
to maintain twitter for 0.6? branches/0.6 is where it should go.
That's the latest version of the plugin that's being worked on for
0.6. Done a great change in there that you think should be trunk (and
you're happy to make it work with the latest verion)? merge it. Once
again, if you check out a branch, it's the latest _developmental_
version of that plugin for that version of habari.

tags: Hey wow, i think this is a great release. it seems relatively
bug free, and i know it works with this version of habari, and it even
has it's own version (say, version 0.1). Call it tags/0.6-0.1. Now
when end user wants a version of a plugin that works with their
version of habari, they can check out the tagged copy.

A couple of supporting aspects.

* use of svn:externals doesn't break here. You can use trunk, and if
it breaks, you can fix it or whine on. (my primary concern btw)
* For cases where maintenance of the svn tree is poor for a plugin,
everything will be (predictably) in trunk. I don't have to hunt around
the tree for where the current dev is.
* This layout follows the design of version control as far as i
understand it.
* This is the layout recommended by the subversion book (), making it
about as standard as these things can get. From
http://svnbook.red-bean.com/en/1.5/svn-book.html: "While Subversion's
flexibility allows you to lay out your repository in any way that you
choose, we recommend that you create a trunk directory to hold the
'main line' of development, a branches directory to contain branch
copies, and a tags directory to contain tag copies."

Sorry i've come into this late, but i think this is kinda important.

Cheers! (and thanks to ringmaster for his patience when i first came
screaming into the irc channel :) )

Edit: Removed message from old thread to put it here.

[Michael Bishop]

Might I add, that already there are plugins that have been updated in
their trunk, and not branched, so we are creating a complete nightmare
for people to find the right version.

~miklb

[Ali B.]

The idea is to eventually avoid that "nightmare".

Plugins zip's would be built from tags that are created on the different plugins branches. For stable versions of plugins, ie branched and tagged for the latest stable habari release, users will be able to download that specific zip. People running habari head HEAD, will need to check out the plugins from their habari upcoming versions branches using svn (They are running habari dev, you'd assume that there would not be an issue running a dev versions of the plugins).

This would mainly allow easy developement and release for more than one plugin version for the same habari version. I don't see how this can be done all within trunk without having to revert changes, tag and then reapply. Quite messy.

Another problem with the past setup is that we cannot keep packaging plugin's trunk. Plugin's trunk is, normally, used for developement and not stable releases.

Because -extras is currently in this transition, You should obviously expect some sort of mess. Evnetually, all plugins will have a branch for the current version (and it's major point version), and (if required), a branch for the alpha version currently in developement.

This will, as a result, deem trunks obsolete. Unless you want to merge back from the latest branch back to it when you want to create a new branch.

One last thing to add is that with or without the new svn "restructure", plugins' trunks will break for people running 0.6 since most of them will be up'ed to be used with the latest habari HEAD.

--
Ali B. / dmondark
http://awhitebox.com

[Michael Bishop]

On Jun 25, 3:08 am, "Ali B." <dmond...@gmail.com> wrote:
> The idea is to eventually avoid that "nightmare".
>
> Plugins zip's would be built from tags that are created on the different
> plugins branches. For stable versions of plugins, ie branched and tagged for
> the latest stable habari release, users will be able to download that
> specific zip. People running habari head HEAD, will need to check out the
> plugins from their habari upcoming versions branches using svn (They are
> running habari dev, you'd assume that there would not be an issue running a
> dev versions of the plugins).

No, tags should be created from trunk, not a branch as I understand
subversion and version control. Branches can be for development, but
should be eventually merged back into trunk, same as we do with core.

If and when we were to get to 2.0, then yes, there'd be a 1.x branch
I'd assume.

>
> This would mainly allow easy developement and release for more than one
> plugin version for the same habari version. I don't see how this can be done
> all within trunk without having to revert changes, tag and then reapply.
> Quite messy.

I don't understand. "more than one plugin version for the same habari
version"? why would there be different versions of the same plugin
that work with a specific version of Habari? If they are that
different, then the plugin should be forked and have it's own separate
branches/tags/trunk hierarchy.

> Another problem with the past setup is that we cannot keep packaging
> plugin's trunk. Plugin's trunk is, normally, used for developement and not
> stable releases.

Agreed. Zips should be built from tags.

> Because -extras is currently in this transition, You should obviously expect
> some sort of mess. Evnetually, all plugins will have a branch for the
> current version (and it's major point version), and (if required), a branch
> for the alpha version currently in developement.

Again, this is where we differ. I don't understand why trunk wouldn't
be used for current development. Sure, one might create a branch for
something extremely ambitious (again, same as we do with core, think
Monolith), but it would be merged back to trunk once deemed ready, not
tagged from there.

> This will, as a result, deem trunks obsolete. Unless you want to merge back
> from the latest branch back to it when you want to create a new branch.

Yes. The way I see it is once .7 is gold, we merge that branch back
into trunk, potentially tag a stable release, and go about our merry
way. We won't be supporting .6, so why would we bother with trying to
legacy support plugins for that version? As far as when we get to
1.0, the way I understand versioning, there shouldn't be any drastic
changes to the codebase in 1.x as to need separate branches for each
point release.

> One last thing to add is that with or without the new svn "restructure",
> plugins' trunks will break for people running 0.6 since most of them will be
> up'ed to be used with the latest habari HEAD.
>

See, the way I understood it, the whole reason we did this .6/.7
branching was so that people running .6 could still download the
plugins from -extras dist and work with their version (as the zips are
still built from trunk). However, that hasn't been followed across
the board. Code Escape and Database Optimizer were two that I ran
across that were updated in trunk for .7, but weren't branched at all,
nor did I see a .6 tag. So we aren't collectively even following the
same process.

I just don't understand why we would adopt a completely different
method of development for plugins than core. I mean, I get that we
branched for .7 changes, as nothing is completely set in stone for the
pluggable method, and we haven't worked out a solution for offering
downloads.

We aren't abandoning trunk for core are we? By this system, we would
be doing all of the development to core in a .7 branch, tag a release
from there, and then start a .8 branch, wash-rinse-repeat…

Anyway, I don't want to sound like I'm beating a dead horse, or come
across as too argumentative. I've expressed my opinion, and will wait
to (hopefully) hear what others have to say.

~miklb

[Michael C. Harris]

2009/6/25 Michael Bishop <mi...@bloggingmeta.com>

On Jun 25, 3:08 am, "Ali B." <dmond...@gmail.com> wrote:
> The idea is to eventually avoid that "nightmare".
>
> Plugins zip's would be built from tags that are created on the different
> plugins branches. For stable versions of plugins, ie branched and tagged for
> the latest stable habari release, users will be able to download that
> specific zip. People running habari head HEAD, will need to check out the
> plugins from their habari upcoming versions branches using svn (They are
> running habari dev, you'd assume that there would not be an issue running a
> dev versions of the plugins).

No, tags should be created from trunk, not a branch as I understand
subversion and version control.  Branches can be for development, but
should be eventually merged back into trunk, same as we do with core.

If and when we were to get to 2.0, then yes, there'd be a 1.x branch
I'd assume.

I express no opinion, but tags can be created from anywhere, and version branches are common. A branch in a plugin that is compatible with a stable version of Habari, and from which tags are made is reasonable for bug fixes etc.

[Ali B.]

On Thu, Jun 25, 2009 at 11:09 AM, Michael Bishop <mi...@bloggingmeta.com> wrote:

On Jun 25, 3:08 am, "Ali B." <dmond...@gmail.com> wrote:
> The idea is to eventually avoid that "nightmare".
>
> Plugins zip's would be built from tags that are created on the different
> plugins branches. For stable versions of plugins, ie branched and tagged for
> the latest stable habari release, users will be able to download that
> specific zip. People running habari head HEAD, will need to check out the
> plugins from their habari upcoming versions branches using svn (They are
> running habari dev, you'd assume that there would not be an issue running a
> dev versions of the plugins).

No, tags should be created from trunk, not a branch as I understand
subversion and version control.  Branches can be for development, but
should be eventually merged back into trunk, same as we do with core.

If and when we were to get to 2.0, then yes, there'd be a 1.x branch
I'd assume.

That's often true. Although not in this case. See my answer for the multiple plugin version per habari release below.

>
> This would mainly allow easy developement and release for more than one
> plugin version for the same habari version. I don't see how this can be done
> all within trunk without having to revert changes, tag and then reapply.
> Quite messy.

I don't understand.  "more than one plugin version for the same habari
version"?  why would there be different versions of the same plugin
that work with a specific version of Habari?  If they are that
different, then the plugin should be forked and have it's own separate
branches/tags/trunk hierarchy.

Say you have a plugin you are currently developing it for Habari 0.6. You've come to a point where you want to release it, but the feature would still work on 0.6 so you tag it as 0.6-0.1 (0.1 is the plugin version). Then you add cool feature or fix a nasty bug to that plugin and want to release that feature. You tag it 0.6-0.2. That's multiple plugin version for one Habari version.

> Another problem with the past setup is that we cannot keep packaging
> plugin's trunk. Plugin's trunk is, normally, used for developement and not
> stable releases.

Agreed.  Zips should be built from tags.

> Because -extras is currently in this transition, You should obviously expect
> some sort of mess. Evnetually, all plugins will have a branch for the
> current version (and it's major point version), and (if required), a branch
> for the alpha version currently in developement.

Again, this is where we differ.  I don't understand why trunk wouldn't
be used for current development.  Sure, one might create a branch for
something extremely ambitious (again, same as we do with core, think
Monolith), but it would be merged back to trunk once deemed ready, not
tagged from there.

Contiuning from my answer on the previous quesion: What if, within the intial release of the plugin (plugin version 0.1), you wanted to have a version that is compatible with Habari 0.7? You create a branch from the trunk for Habari 0.7 support and make the plugin compatible with 0.7. You tag it 0.7-0.1. When you want to add the cool feature or fix the nasty bug on the 0.7 "edition" of the plugin, you commit your change and tag that branch 0.7.
 

> This will, as a result, deem trunks obsolete. Unless you want to merge back
> from the latest branch back to it when you want to create a new branch.

Yes.  The way I see it is once .7 is gold, we merge that branch back
into trunk, potentially tag a stable release, and go about our merry
way.  We won't be supporting .6, so why would we bother with trying to
legacy support plugins for that version?  As far as when we get to
1.0, the way I understand versioning, there shouldn't be any drastic
changes to the codebase in 1.x as to need separate branches for each
point release.

An important difference to note between the -core and -extras is that with -extras the code would/may need to conform with more than one -core versions at a given time. While -core, you don't have to to conform with anything.

> One last thing to add is that with or without the new svn "restructure",
> plugins' trunks will break for people running 0.6 since most of them will be
> up'ed to be used with the latest habari HEAD.
>

See, the way I understood it, the whole reason we did this .6/.7
branching was so that people running .6 could still download the
plugins from -extras dist and work with their version (as the zips are
still built from trunk).  However, that hasn't been followed across
the board.  Code Escape and Database Optimizer were two that I ran
across that were updated in trunk for .7, but weren't branched at all,
nor did I see a .6 tag.  So we aren't collectively even following the
same process.

It's true. Few plugins have had their trunk updated. Making it a little harder for other contributers to create a habari 0.6 branches. This can obvioulsy fixed by branching for 0.7, reverting changes from trunk, and branching for 0.6. A pain, but will need to be done eventually. Otherwise, no zips will be generated for these plugins.

I just don't understand why we would adopt a completely different
method of development for plugins than core.  I mean, I get that we
branched for .7 changes, as nothing is completely set in stone for the
pluggable method, and we haven't worked out a solution for offering
downloads.

We aren't abandoning trunk for core are we?  By this system, we would
be doing all of the development to core in a .7 branch, tag a release
from there, and then start a .8 branch, wash-rinse-repeat…

See my answer re "-core and -extras" above :)

Anyway, I don't want to sound like I'm beating a dead horse, or come
across as too argumentative. I've expressed my opinion, and will wait
to (hopefully) hear what others have to say.

Ditto.

[Michael C. Harris]

2009/6/25 Ali B. <dmon...@gmail.com>:

>
> On Thu, Jun 25, 2009 at 11:09 AM, Michael Bishop <mi...@bloggingmeta.com> wrote:
>>
>> Again, this is where we differ.  I don't understand why trunk wouldn't
>> be used for current development.  Sure, one might create a branch for
>> something extremely ambitious (again, same as we do with core, think
>> Monolith), but it would be merged back to trunk once deemed ready, not
>> tagged from there.
>
> Contiuning from my answer on the previous quesion: What if, within the
> intial release of the plugin (plugin version 0.1), you wanted to have a
> version that is compatible with Habari 0.7? You create a branch from the
> trunk for Habari 0.7 support and make the plugin compatible with 0.7. You
> tag it 0.7-0.1. When you want to add the cool feature or fix the nasty bug
> on the 0.7 "edition" of the plugin, you commit your change and tag that
> branch 0.7.

Why not have trunk compatible with 0.7 and tag from there ? Fixes for
nasty bugs can be committed to trunk and merged to the 0.6 branch.

[Ali B.]

On Thu, Jun 25, 2009 at 11:39 AM, Michael C. Harris <michael...@gmail.com> wrote:

2009/6/25 Ali B. <dmon...@gmail.com>:

>
> On Thu, Jun 25, 2009 at 11:09 AM, Michael Bishop <mi...@bloggingmeta.com> wrote:
>>

>> Again, this is where we differ.  I don't understand why trunk wouldn't
>> be used for current development.  Sure, one might create a branch for
>> something extremely ambitious (again, same as we do with core, think
>> Monolith), but it would be merged back to trunk once deemed ready, not
>> tagged from there.
>
> Contiuning from my answer on the previous quesion: What if, within the
> intial release of the plugin (plugin version 0.1), you wanted to have a
> version that is compatible with Habari 0.7? You create a branch from the
> trunk for Habari 0.7 support and make the plugin compatible with 0.7. You
> tag it 0.7-0.1. When you want to add the cool feature or fix the nasty bug
> on the 0.7 "edition" of the plugin, you commit your change and tag that
> branch 0.7.

Why not have trunk compatible with 0.7 and tag from there ? Fixes for
nasty bugs can be committed to trunk and merged to the 0.6 branch.

That may work. Although, if there are significant changes between 0.7-compatible plugin code and 0.6-compatible (or any two successive habari versions, for that matter), merging may not be as easy and probably won't appeal to many.

[Michael C. Harris]

2009/6/25 Ali B. <dmon...@gmail.com>

That will be an issue wherever the fix is coming from, whether trunk or a branch. Thankfully, plugins tend to be small, so fixing a merge shouldn't be too hard. 

[Ali B.]

On Thu, Jun 25, 2009 at 11:53 AM, Michael C. Harris <michael...@gmail.com> wrote:

2009/6/25 Ali B. <dmon...@gmail.com>

On Thu, Jun 25, 2009 at 11:39 AM, Michael C. Harris <michael...@gmail.com> wrote:

2009/6/25 Ali B. <dmon...@gmail.com>:

>
> On Thu, Jun 25, 2009 at 11:09 AM, Michael Bishop <mi...@bloggingmeta.com> wrote:
>>

>> Again, this is where we differ.  I don't understand why trunk wouldn't
>> be used for current development.  Sure, one might create a branch for
>> something extremely ambitious (again, same as we do with core, think
>> Monolith), but it would be merged back to trunk once deemed ready, not
>> tagged from there.
>
> Contiuning from my answer on the previous quesion: What if, within the
> intial release of the plugin (plugin version 0.1), you wanted to have a
> version that is compatible with Habari 0.7? You create a branch from the
> trunk for Habari 0.7 support and make the plugin compatible with 0.7. You
> tag it 0.7-0.1. When you want to add the cool feature or fix the nasty bug
> on the 0.7 "edition" of the plugin, you commit your change and tag that
> branch 0.7.

Why not have trunk compatible with 0.7 and tag from there ? Fixes for
nasty bugs can be committed to trunk and merged to the 0.6 branch.

That may work. Although, if there are significant changes between 0.7-compatible plugin code and 0.6-compatible (or any two successive habari versions, for that matter), merging may not be as easy and probably won't appeal to many.

That will be an issue wherever the fix is coming from, whether trunk or a branch. Thankfully, plugins tend to be small, so fixing a merge shouldn't be too hard. 

True. So create branches for released Habari versions and have trunk always support the current alpha? That would actually work better if I'm not missing something.

[Chris J. Davis]

Or create tags for released Habari versions and make updates/bug fixes there.

Do you know what the difference between a tag and a branch is? Nothing but a naming convention. They are exactly the same. What makes them differ is how they are used.  

I am concerned that we are goingbro introduce a stumbling block to new devs coming in by creating a non standard use of svn. Active dev is done in trunk, released versions of code are in tags and new features that could aignifigantly destabilize trunk are done in branches, which by their very nature are short lived. 

This is my two cents anyway.   

Sent from my iPhone

[Michael C. Harris]

2009/6/25 Chris J. Davis <c...@chrisjdavis.org>

Or create tags for released Habari versions and make updates/bug fixes there.

Do you know what the difference between a tag and a branch is? Nothing but a naming convention. They are exactly the same. What makes them differ is how they are used.  

Yes, I do know. I think it's a terrible idea to do development in a tag because ...

 

I am concerned that we are goingbro introduce a stumbling block to new devs coming in by creating a non standard use of svn. 

... oh, you just made my point for me :)

 -- 

[Caius Durling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25 Jun 2009, at 10:35, Chris J. Davis wrote:

> Do you know what the difference between a tag and a branch is?
> Nothing but a naming convention. They are exactly the same. What
> makes them differ is how they are used.

There _is_ a difference between them which is why they are named
differently. Technically they are both just sub-folders yes, but you
shouldn't just use them as the same.

C
- ---
Caius Durling
ca...@caius.name
+44 (0) 7960 268 100
http://caius.name/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEUEARECAAYFAkpDVR8ACgkQlj5WkEOM/Nie2QCgjFUbghE1pRgIVziWygs/lrdc
9fIAmMa0ypAd6djNXpLWAjBqLc3DGls=
=o76W
-----END PGP SIGNATURE-----

[Caius Durling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25 Jun 2009, at 10:35, Chris J. Davis wrote:

> I am concerned that we are goingbro introduce a stumbling block to
> new devs coming in by creating a non standard use of svn. Active dev
> is done in trunk, released versions of code are in tags and new
> features that could aignifigantly destabilize trunk are done in
> branches, which by their very nature are short lived.

*claps* Totally agree.

(Sorry for the last email, should've read further on before replying
to you Chris.)

C
- ---
Caius Durling
ca...@caius.name
+44 (0) 7960 268 100
http://caius.name/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkpDVVcACgkQlj5WkEOM/NjMtgCgn+34hLU9EczjTS1yfX16vyeJ
BsgAoLUVwxQkmnAhi0DIooHaL/VOSEa6
=R2ZA
-----END PGP SIGNATURE-----

[luke]

>
> Yes, I do know. I think it's a terrible idea to do development in a tag
> because ...
>
> > I am concerned that we are goingbro introduce a stumbling block to new devs
> > coming in by creating a non standard use of svn.
>
> ... oh, you just made my point for me :)
>
>  --
> Michael C. Harris, School of CS&IT, RMIT Universityhttp://twofishcreative.com/michael/blog
> IRC: michaeltwofish #habari

Entirely agreed. Which is also why i made my earlier points about the
purpose of trunk vs branches. Main dev is in trunk. This is the
standard use of svn. If you want to make a version of a plugin for an
older version, branch it and do it. The trunk should be working
towards working with the current version of habari. if there needs to
be work done on a prior version, branch it. that means trunk is always
latest.

> I express no opinion, but tags can be created from anywhere, and version
> branches are common. A branch in a plugin that is compatible with a stable
> version of Habari, and from which tags are made is reasonable for bug fixes
> etc.

Agreed. You can easily create a tag from a branch.

<storyteller>

Indeed you would if you wanted to release a new version of an plugin
for an old version of habari. ie lets say we're up to 0.8, and you
found a security bug in your plugin, that you have previously released
version 0.1 for 0.6 and 0.2 for 0.7 and 0.6. For updating releases to
fix code bugs, lets assume for the moment you use release version
numbers (ie 0.0.x) so the plugin would be currently laid out thus
(you're a very clean person, and you clean up your branche):

plugin
\trunk <- main dev of your plugin for 0.8
\branches
\tags
\0.6-0.1
\0.6-0.2
\0.7-0.2

Now you start work on your bug. You need to make two new releases. So
you create thus:

\trunk <- main dev for 0.8
\branches
\0.6-0.2.1
\0.7-0.2.1
\tags
\0.6-0.1
\0.6-0.2
\0.7-0.2

You might have branched from the last tag, or the trunk. whatever you
felt was easier. Then you fix your buggy code, and you want to release
it to the world. Now we have:

\trunk <- main dev for 0.8
\branches
\tags
\0.6-0.1
\0.6-0.2
\0.6-0.2.1
\0.7-0.2
\0.7-0.2.1

You are not ready to release your plugin for 0.8, because you want it
to have laser beams, and they are not ready on the internets yet.

NOW! What happens is I come along, and i have 0.7 of habari, so i get
the highest version in the 0.7 set that i can. Oh look! it's
0.7-0.2.1. I don't know what that scary trunk is, so i leave it alone.
Or, i have 0.6, so i get the tag of 0.6-0.2.1.

Alternately, i am super-dev, and i only ever run trunk of habari. In
this case, i can check out from trunk, and be a leet hacker coder.

One more case: Let's say, 0.8 got released yesterday, and i want this
plugin. I have a couple of choices.
a) I can wait for the author to release a 0.8 tag. This is what will
show up whenever on plugin sites anyway.
b) i can be adventurous, and see if a previous tag works. From here,
two options
b) i) It works. Yay i tell a habari dev, and they retag as a release
after a bit of testing
b ii) It doesn't work. Either i try to fix, or see options a) or c).
c) I can be adventurous, and see if trunk works. From here, same two
options as b).

</storyteller>

RIGHT. so i've now laid out the use cases where i see them fit. I
think that this layout is the most consistent with the original
designs of standard svn layouts (to address michael's concern's about
accessibility), and i also think this i the most maintainable
(addressing others concerns). I also think that this is the most
detailed proposition so far. I would like to see the other options
laid out with these use cases, as i have no particular affinity with
this solution, i just don't think the others work as well.

Cheers!

[Caius Durling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25 Jun 2009, at 03:20, Michael Bishop wrote:

> I understand the reasoning for doing branches on the recent major
> changes to plugins (from the info method to using XML), however, it's
> being discussed that we will stop using trunk for the plugins
> development, and use branches from here on out.
>
> I'm a giant, -1 on this. Once .7 is released, if not sooner, we
> should go back to using the traditional, trunk/branches/tags system.
> It makes absolutely zero sense to continue primary development in
> branches at that point. We will not be supporting .6 after .7 is
> released, so why should we not use trunk? We will have the .6
> branches for those who for what ever reason aren't ready to upgrade,
> but otherwise, we should go back to the former system.

I'm a -1 on this as well.

We're a pretty forward-thinking bunch of people, and for the most part
we either run the latest stable or HEAD. At the very least we run the
latest 0.x release (0.6 currently) to get the latest features in
plugins. So my question is: why would features from a 0.7 version of a
plugin be backported to a 0.6 version of that plugin? If you want the
features, upgrade your habari install and go frolic in the meadows
with the ponies.

C
- ---
Caius Durling
ca...@caius.name
+44 (0) 7960 268 100
http://caius.name/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkpDWXUACgkQlj5WkEOM/NiCigCfSdGSS88RKkA6bRf7OchOuDGo
j5wAoNZG0hnZloLthNOF8Sb33sg8GyHw
=iQ7H
-----END PGP SIGNATURE-----

[Ali B.]

If you want the
features, upgrade your habari install and go frolic in the meadows
with the ponies.

What does this mean? Can you please embrace the fact that not everyone on the list may understand the pony-slang-thing? Thanks!

I have to admit that I find it puzzling why we waited around a week from when we did started branching the plugins before discussing this. Also, the original post[1] was posted about 5 weeks ago. I can't help but to wonder why no one opposed this at that time?

[1] http://groups.google.com/group/habari-dev/browse_frm/thread/53b99ed317f91b64/630774ced1b012e6?lnk=gst&q=extras&pli=1

 

[Ryan Mullins]

I'm actually in a holding pattern as far as updating my plugins to see if this all changes again.

My $0.02:  branch, tag, trunk  it's all semantics.  Just let me know where you want it.  :)

[Chris J. Davis]

You make a good point my friend. I know for my part i was under the impression that we were only doing this because of the info change. 

I missed that it was supposed to be permanent. 

Sent from my iPhone

[Owen Winkler]

luke wrote:
>
> I am a habari user, and plugin writer. I haven't worked on core code,
> although i have code dived (diven?). We're basically starting to roll
> out habari to most of our clients. It's becoming our software of
> choice. That's where we are coming from.

If this is the case, then having a sane way to maintain plugins for
clients who, for one reason or another (usually "don't want to pay to
upgrade core"), won't upgrade Habari.

Let's just correct this one thing right now: Letting trunk whither is a
mistake.

We talked about theoretically back when we started this conversation,
and that's the conclusion we came to. It was wrong. Let's move on.

Apart from that one change - letting trunk stay and be active - I think
we should stick with the plan as described, and I will explain not only
how it will benefit you, but also how another large project with a huge
contributor base does nearly the exact same thing to great effect.

Trunk is for new development. Unless you are a dev for the plugin, you
don't use trunk.

Branches are for maintaining security releases for old versions of the
plugin. We have 0.6 and 0.7 branches for many plugins now. The main
reason for this is that trunk code, if it is the latest 0.7 version,
will not work on 0.6. 0.6 is our stable release version of Habari. If
a user comes to download plugins for their stable release install,
they're going to want 0.6, not 0.7/trunk.

Branches can also be for experimental work. That's fine. But we -
plugin developers - also need to agree on a single place from which
security-supported updates will derive. In plugins for 0.x versions of
Habari, this isn't going to be as important as for major versions.
Major versions of Habari may linger for much, much longer, and the
plugins for older versions will need to be maintained while the new ones
are worked on. If you want to be forward-thinking, think in that
direction, please.

But people who want stable releases really shouldn't be downloading
branch versions of plugins either, because that's where the work goes to
produce a release. If someone wants to test a preview release of a
plugin, they can grab it out of the branch for their version of Habari.
Pre-release code should not be tagged.

When you tag a plugin, that's the trigger for the system to produce a
distribution package of the plugin. No, this system is not built yet.
But my thought is to have a build system that will produce packages of
anything tagged with a version number matching our x.x-x.x scheme, and
anything in a branch with a version number matching that scheme.

A new page somewhere on the site would list versions available of a
plugin. It would be very clear: "This is the stable release for 0.6"
"This is an in-development (branch) release for 0.7"

We might even produce a zip of trunk for convenience, but if you're
using trunk code, you should probably pull it from subversion.

A lot of this organization is pre-planning for when we get to a 1.0
release, and we need plugin branches that work with one or the other
because we'll have to support old major versions of Habari that have
been included in long-life distros. That's a nice goal, right? We need
a plan for that. This is part of that plan. Right now it looks
confusing because the changes in plugins/core aren't big enough. But if
you imagine the timeline much farther out, hopefully this will make more
sense. Starting now, setting things up that way now, will reduce pain
from transition later when it'll matter more.

If you're updating plugins with svn:externals, this is all going to seem
like a pain in the butt. But trust my experience from doing this in the
past -- you do not want to do this anyway. If a plugin's trunk goes off
the deep end, and you update to it, you will be in for a world of pain
getting things back. Instead, if you must, external to a tag (or at
worst, a branch) and then re-point your externals when you update. Yes,
it's a pain. That's why I'm saying "don't do this". I'm sure someone
can write a script (and this sort of thing could be part of a plugin --
I've seen source for it) that will update plugins to their latest stable
tag/branch, and that will be a better solution.

For people complaining that this doesn't work like Habari core does,
apart from the trunk issue that I've conceded above, it's remarkably
similar. The only difference between this and the makaanga branch is
that the plugin makaanga is simply a specifically-named (by version)
branch in the repo. That's it.

Dare I say it...

Drupal has been using this scheme for developing their contributed
plugins for some time. If you look at any of the Drupal project pages
for their modules, you'll see more or less what I've described. The
only differences in the plan as outlined from what Drupal does are that
Drupal uses CVS and they are able to mark branches as recommended for
use with major core versions. This is mostly due to limitations of CVS.
Tagging a copy in svn will do the same thing for us.

I'm not saying that their system is perfect and ours needs to be
identical. What I am saying is that you can look at Drupal as a working
model, and any other speculation as to what might work better is just
speculation.

As to the issue of plugin developers who have updated trunk to 0.7
without branching for 0.6 -- YOU HAVE SCREWED UP, but all is not lost.

Figure out where your plugin was last 0.6-compatible, and branch the
code to an 0.6-y.x branch from that revision.

I think that we can all agree that some system is needed to address the
issue of compatibility between branches. My premise is that it's going
to be more important for users to find and use the correct version of
their plugins than it is to reduce the pain of a couple "svn switch"
calls. Yes, it's going to expose lots of out-of-date plugins. No, I
don't have an immediate solution for plugins that would continue to work
for future versions of Habari even if they're not updated in branches.

I guess what I'm saying is that any system is likely to have some
weakness, and what I've seen suggested in this thread so far more
resembles a plan you would assemble for a single core open source
project than a collection of supplementary collaborative projects.

The solution for -extras is by necessity likely to be different than
what you're used to if you've worked only on core project repos. To
that end, the initial planning (which few others deigned worthwhile to
participate in at the time, I'll add) was modeled after a generally
successful implementation of that concept. Please keep this in mind as
you make suggestions for the betterment of the extras repo.

Owen

[luke]

Firstly things first.

> I have to admit that I find it puzzling why we waited around a week from
> when we did started branching the plugins before discussing this. Also, the
> original post[1] was posted about 5 weeks ago. I can't help but to wonder
> why no one opposed this at that time?

For this, I apologise. Although i've been hanging out in irc for a
while, i haven't really been following the mailing list, as i should.
I only found out about the change when JibbyBot started posting
changesets. Once again, I apologise.

On Jun 25, 11:48 pm, Owen Winkler <epit...@gmail.com> wrote:
> luke wrote:
>
> > I am a habari user, and plugin writer. I haven't worked on core code,
> > although i have code dived (diven?). We're basically starting to roll
> > out habari to most of our clients. It's becoming our software of
> > choice. That's where we are coming from.
>
> If this is the case, then having a sane way to maintain plugins for
> clients who, for one reason or another (usually "don't want to pay to
> upgrade core"), won't upgrade Habari.

Agreed.

>
> Let's just correct this one thing right now:  Letting trunk whither is a
> mistake.
>
> We talked about theoretically back when we started this conversation,
> and that's the conclusion we came to.  It was wrong.  Let's move on.

Yay! This makes me happy

>
> Apart from that one change - letting trunk stay and be active - I think
> we should stick with the plan as described, and I will explain not only
> how it will benefit you, but also how another large project with a huge
> contributor base does nearly the exact same thing to great effect.
>

Sure. Could you clarify how this differs from what i outlined above?
I'm not sure i see a difference (which would be great), but i just
want to make sure i'm not missing things.

>
> But people who want stable releases really shouldn't be downloading
> branch versions of plugins either, because that's where the work goes to
> produce a release.  If someone wants to test a preview release of a
> plugin, they can grab it out of the branch for their version of Habari.
> Pre-release code should not be tagged.

Big +1 to this one.

>
> When you tag a plugin, that's the trigger for the system to produce a
> distribution package of the plugin.  No, this system is not built yet.
> But my thought is to have a build system that will produce packages of
> anything tagged with a version number matching our x.x-x.x scheme, and
> anything in a branch with a version number matching that scheme.
>
> A new page somewhere on the site would list versions available of a
> plugin.  It would be very clear:  "This is the stable release for 0.6"
> "This is an in-development (branch) release for 0.7"
>
> We might even produce a zip of trunk for convenience, but if you're
> using trunk code, you should probably pull it from subversion.

Yup. Agreed.

>
> If you're updating plugins with svn:externals, this is all going to seem
> like a pain in the butt.  But trust my experience from doing this in the
> past -- you do not want to do this anyway.  If a plugin's trunk goes off
> the deep end, and you update to it, you will be in for a world of pain
> getting things back.  Instead, if you must, external to a tag (or at
> worst, a branch) and then re-point your externals when you update.  Yes,
> it's a pain.  That's why I'm saying "don't do this".  I'm sure someone
> can write a script (and this sort of thing could be part of a plugin --
> I've seen source for it) that will update plugins to their latest stable
> tag/branch, and that will be a better solution.

I would have much prefered to external to a tag. however when i
started doing this, there weren't any (useful ones) :)

[snip]

Soooo. this all sounds pretty good. I have one last being-the-annoying-
guy thing. This needs to be written up as documentation somewhere so
that plugin developers follow it. Probably the wiki. Otherwise it's
just talking. Thoughts? Is there a better location?

Luke

[Michael C. Harris]

2009/6/29 luke <lu...@squareweave.com.au>:

> Owen wrote:
>> Apart from that one change - letting trunk stay and be active - I think
>> we should stick with the plan as described, and I will explain not only
>> how it will benefit you, but also how another large project with a huge
>> contributor base does nearly the exact same thing to great effect.

To summarise, I think this is where we stand in regard to plugins:
(and please point out here if I've missed anything or I'm wrong)

* trunk is for active development, it's unstable, and people using it
should use svn. Currently, trunk should work for 0.7.
* On release of a version of Habari, a tag should be created. Use it
as an external if you like. If the plugin hasn't changed since the
last release and still works, you can just copy the previous tag. If
there isn't an appropriate tag, you might consider creating one.
Currently there should be a 0.6-(\d+).(\d+) tag for all plugins.
* If there are fixes for a plugin targeted at a released version, a
branch should be made from the appropriate tag, the fix made, and a
new version tagged. There's no need to automatically create a branch
when a release of Habari is made.
* Tagged things should have a distribution created automatically
(which doesn't happen yet, but when it does it should tie into the
addons directory).
* Other branches can exist for experimental features, and you can do
whatever you like with them.

To move forward from here:
* Ensure there is an appropriate and working 0.6 tag. In most cases
this will mean tagging the 0.6 branch after testing. In the few cases
where no 0.6 tag or branch was made, it will mean branching an earlier
revision for 0.6, testing (and removing the XML file if there was one)
and tagging from there.
* Make sure trunk works with 0.7. In most cases this will mean merging
the 0.7 branch back to trunk. Where trunk has been removed, it needs
to be restored.

> Soooo. this all sounds pretty good. I have one last being-the-annoying-
> guy thing. This needs to be written up as documentation somewhere so
> that plugin developers follow it. Probably the wiki. Otherwise it's
> just talking. Thoughts? Is there a better location?

The right location for documentation is
http://wiki.habariproject.org/en/Extras_Repository.

--

[Ali B.]

On Mon, Jun 29, 2009 at 2:10 AM, luke <lu...@squareweave.com.au> wrote:

Firstly things first.

>> I have to admit that I find it puzzling why we waited around a week from
>> when we did started branching the plugins before discussing this. Also, the
>> original post[1] was posted about 5 weeks ago. I can't help but to wonder
>> why no one opposed this at that time?

> For this, I apologise. Although i've been hanging out in irc for a
> while, i haven't really been following the mailing list, as i should.
> I only found out about the change when JibbyBot started posting
> changesets. Once again, I apologise.

No need, luke. In fact, thanks for bringing the topic up for discussion.

On Mon, Jun 29, 2009 at 2:44 AM, Michael C. Harris <michael...@gmail.com> wrote:

2009/6/29 luke <lu...@squareweave.com.au>:

> Owen wrote:
>> Apart from that one change - letting trunk stay and be active - I think
>> we should stick with the plan as described, and I will explain not only
>> how it will benefit you, but also how another large project with a huge
>> contributor base does nearly the exact same thing to great effect.

To summarise, I think this is where we stand in regard to plugins:
(and please point out here if I've missed anything or I'm wrong)

[snip all the summary]

This all sounds good to me at least. Merging is not going to be easy for people with few or no svn flying hours. But as you said, plugins are normally small and the changes made are often straight forward.

--

Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari

[Michael C. Harris]

2009/6/29 Michael C. Harris <michael...@gmail.com>:

>
> To summarise, I think this is where we stand in regard to plugins:
> (and please point out here if I've missed anything or I'm wrong)

[snip summary]

There's been very little comment (thanks Ali), so I've gone ahead and
added information about how things should be structured to the wiki.

http://wiki.habariproject.org/en/Extras_Repository#Repository_Structure

If you have any problems with it _please_ speak up now before people
start restructuring again.

> To move forward from here:
> * Ensure there is an appropriate and working 0.6 tag. In most cases
> this will mean tagging the 0.6 branch after testing. In the few cases
> where no 0.6 tag or branch was made, it will mean branching an earlier
> revision for 0.6, testing (and removing the XML file if there was one)
> and tagging from there.
> * Make sure trunk works with 0.7. In most cases this will mean merging
> the 0.7 branch back to trunk. Where trunk has been removed, it needs
> to be restored.

[Sean Coates]

Digging up an old thread, here.

On Jun 28, 6:44 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:

> Currently there should be a 0.6-(\d+).(\d+) tag for all plugins.

This should read "for all plugins that have a 0.6-compatible version",
I think.

Anyway, my real question: How do we name versions that are in
development?

Say I have a 0.7-0.1 plugin, and I tag it. That's fine.
Then I start working in trunk on 0.7-0.2. I don't want to actually
name it 0.7-0.2 yet because I want the version number to be distinct
from the _actual_ 0.7-0.2 (the one I'll eventually release).

In PHP/PECL, we'd name this "0.2-dev". Is 0.7-0.2-dev too cumbersome?

Other ideas? I'm open to anything, but I do think we should all follow
the same scheme.

S

[Sean Coates]

Anyway, my real question: How do we name versions that are in
development?

Say I have a 0.7-0.1 plugin, and I tag it. That's fine.
Then I start working in trunk on 0.7-0.2. I don't want to actually
name it 0.7-0.2 yet because I want the version number to be distinct
from the _actual_ 0.7-0.2 (the one I'll eventually release).

In PHP/PECL, we'd name this "0.2-dev". Is 0.7-0.2-dev too cumbersome?

Other ideas? I'm open to anything, but I do think we should all follow
the same scheme.

Discussed this on IRC a bit.

http://drunkenmonkey.org/irc/habari/2009-11-19#T05-54-50

We're thinking that the -dev suffix could be painful.

An idea that kicked around: adding a way to specify that a plugin is unstable to the .plugin.xml.

<version>0.2</version>

<unstable/>

or even

<version stable="false">0.2</version>

Thoughts?

One other question that came up:

Are plugins versions declared as "0.7-0.2" in the XML? or is the 0.7-0.2 convention just for tags?

If the former, might it make more sense to split the two distinct pieces of data into two elements?

<version>

<habari>0.7</habari>

<plugin>0.2</plugin>

</version>

(the tag would still be 0.7-0.2)

Just kicking around ideas; not trying to promote an agenda.

S

[luke]

Hey all,

My view is that the current svn structure works well (http://
pastebin.com/m7a0f75b2 for further description).

I agree that the requirements stuff is a problem. with respect to
this, ithink that we should be following the lead in -core, which is
to do work in the (unnamed) trunk, with a version number in code. The
equivalent to this, as sean has pointed out, is to have a flag in the
xml.

I like the idea of <version stable='false'>0.6</version>. In my mind,
the stability of it is a property of the (to be released) version.

Another pointer for fun (http://drunkenmonkey.org/irc/habari/
2009-11-19#T06-18-38).

Cheers!

[Michael C. Harris]

2009/11/19 Sean Coates <se...@caedmon.net>:

> On Jun 28, 6:44 pm, "Michael C. Harris" wrote:
>> Currently there should be a 0.6-(\d+).(\d+) tag for all plugins.
>
> This should read "for all plugins that have a 0.6-compatible version",
> I think.

That was an aspirational "should", as in "we should all get busy making tags
for 0.6".

2009/11/19 luke <lu...@squareweave.com.au>:

> My view is that the current svn structure works well (http://
> pastebin.com/m7a0f75b2 for further description).

I think we're settled on the current svn structure (I don't think Sean was
suggesting we change that). The issue is, if Mr Punter downloads a version of a
plugin from trunk, and it's version 0.7-0.2, more development happens, then
version 0.7-0.2 is tagged, we have no way of knowing what version they're
using from inside the plugin.

> I like the idea of <version stable='false'>0.6</version>. In my mind,
> the stability of it is a property of the (to be released) version.

I don't mind that either. At least that can tell us the plugin is between rXXX
and rYYY. Of course, people will forget to remove the attribute when
they tag ...

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

Having plugins with version numbers like 0.7-0.x, if that's what is being
suggested, sounds like a bad idea to me. If there are 3 releases of a plugin
for 0.7, a particular download from trunk could be from anywhere in those
releases.

[Owen Winkler]

Michael C. Harris wrote:
>
> I think we're settled on the current svn structure (I don't think Sean was
> suggesting we change that). The issue is, if Mr Punter downloads a version of a
> plugin from trunk, and it's version 0.7-0.2, more development happens, then
> version 0.7-0.2 is tagged, we have no way of knowing what version they're
> using from inside the plugin.

It seems reasonably trivial to add "-dev" to the version of a plugin
that is produced for /dist/plugins from a 0.x branch, assuming the
plugin info xml is well-formed.

For those grabbing the plugin from svn, they can easily tell what
they've got by using `svn info` on the plugin directory, or we could
throw them a bone and add something like what is in Habari's core for
detecting revision information to the Plugins class.

Of particular importance to me in this thread is a sentiment I read in
the IRC log, reproduced for you here:


[06:13:07] <scoates> think of a scenario like this: you have a plugin
called bottle. Another plugin called beer. Beer depends on bottle 0.4 to
work. There'd be a way to programmatically check that you have bottle at
_least_ version 0.4 if it had a 0.4 number. If bottle was called 0.x,
then there'd be no way to check that dependency.


Version number checking like this should NEVER EVER be done.

I've been trying to beat this into everyone for a very long time and I'm
reasonably sure that it's legacy behavior that causes the dissonance.
I'll explain.

Whether a plugin is compatible with the environment it runs in is not a
facet of the version of the plugin. A plugin that uses a single, simple
hook that operates the same way through 4 core versions of Habari should
not need to update its compatibility requirements to keep up with those
Habari releases.

Likewise, a theme that requires a tag cloud should not look for a plugin
named "RNTagCloud" nor should it look for a specific version of a
specifically-named plugin.

Instead, we keep a catalog of feature tags to use in the "requires",
"conflicts", "recommends", and "provides" sections of the plugin info
xml. The core system reports on compatibility between previously
installed items and new items.

The end result includes many positive things:
* Plugins that interoperate with features will continue to work as long
as those features are present, without checking version number
compatibility.
* It will be possible in advance of an upgrade to see not only which
plugins will break, but why.
* It will be possible to provide a list of plugins or themes that will
provide the features that some other plugin or theme requires.

None of that works really well with simple version number checking, and
I believe it's one of the major complaints people have about OBT that I
would personally love to address. Even doing it this way, API
compatibility makes sense to do (since that's how we're delineating core
major versions) by using a "core-1.x" (literally "x") feature tag.

To wrap back around to version numbers: Version numbers are a useful
primary indicator for what version of a plugin is the latest and should
be compatible with the version of Habari that is installed, but they
should not be the ultimate indicator of compatibility. Sorting out
whether a plugin is an in-development version of a
specifically-versioned plugin seems the only real concern, since it
would otherwise be difficult to tell.

Owen

[Sean Coates]

> Whether a plugin is compatible with the environment it runs in is not a
> facet of the version of the plugin. A plugin that uses a single, simple
> hook that operates the same way through 4 core versions of Habari should
> not need to update its compatibility requirements to keep up with those
> Habari releases.

Agreed.

> Likewise, a theme that requires a tag cloud should not look for a plugin
> named "RNTagCloud" nor should it look for a specific version of a
> specifically-named plugin.

Agreed there, too.

> Instead, we keep a catalog of feature tags to use in the "requires",
> "conflicts", "recommends", and "provides" sections of the plugin info
> xml. The core system reports on compatibility between previously
> installed items and new items.

The example in the wiki (http://wiki.habariproject.org/en/pluggable#provides) is:
<provides>
<feature url="http://wiki.habariproject.org/en/feature/podcast">podcast</feature>
</provides>
Does this mean that the "podcast" hooks can never change? What if we have "podcast2"? I guess I just don't understand.

> None of that works really well with simple version number checking, and
> I believe it's one of the major complaints people have about OBT that I
> would personally love to address. Even doing it this way, API
> compatibility makes sense to do (since that's how we're delineating core
> major versions) by using a "core-1.x" (literally "x") feature tag.
>
> To wrap back around to version numbers: Version numbers are a useful
> primary indicator for what version of a plugin is the latest and should
> be compatible with the version of Habari that is installed, but they
> should not be the ultimate indicator of compatibility.

I buy this. (-:
If we have another way to provide compatibility (and it looks like we do, I'd just never noticed.. my fault), then version numbering isn't a good way to check this. I am, still, however, against bucking conventional wisdom and dropping versions from trunk altogether.

> Sorting out
> whether a plugin is an in-development version of a
> specifically-versioned plugin seems the only real concern, since it
> would otherwise be difficult to tell.

You seem to agree. What's your opinion on how to do this?

S

[Sean Coates]

> That was an aspirational "should", as in "we should all get busy making tags
> for 0.6".

I meant that for some plugins there is no, and will never be a 0.6-compatible version (highligher, for example, needs 0.7 functionality).

(My magical mail server just delivered this yesterday; hence the late reply)

S

[Michael C. Harris]

2009/11/22 Sean Coates <se...@seancoates.com>:

>> That was an aspirational "should", as in "we should all get busy making tags
>> for 0.6".
>
> I meant that for some plugins there is no, and will never be a 0.6-compatible version (highligher, for example, needs 0.7 functionality).

Ah, yes, you're entirely correct. I notice subpages got a 0.6 tag
yesterday, but it uses taxonomy classes, so won't work in 0.6.

[ringmaster]

On Nov 19, 11:05 am, Sean Coates <s...@seancoates.com> wrote:
> The example in the wiki (http://wiki.habariproject.org/en/pluggable#provides) is:
> <provides>
>         <feature url="http://wiki.habariproject.org/en/feature/podcast">podcast</feature>
> </provides>
> Does this mean that the "podcast" hooks can never change? What if we have "podcast2"? I guess I just don't understand.

My original idea for this was to use hook/API function signatures for
compatibility. So rather than having a single feature identifier to
represent a number of things, you'd add a bunch of hashes for the
entrypoints your plugin used within Habari.

Explaining how this worked seemed problematic.

So, it seemed better to have a convention that allowed plugin authors
to say that they implement something in a certain way, and
characterize that method with a single, descriptive, *documented*
feature identifier. These features are somewhat analogous to OOP's
Interface idea.

If someone implemented podcasting in a completely different way,
offering a different set of functions, then they'd probably need
"podcast2". Or they could supplement the existing "podcast" feature
with the names of the features they add, like "podcast video".

Truly, "podcast" is a very abstract feature. More documentation
should be done on how these things would best work, he says as he
returns to watching TV.

>
> >   Sorting out
> > whether a plugin is an in-development version of a
> > specifically-versioned plugin seems the only real concern, since it
> > would otherwise be difficult to tell.
>
> You seem to agree. What's your opinion on how to do this?

There needs to be something that marks an in-development version of a
plugin as such, and it needs to be automated. The thing I described
before would do it. Two parts:

1) Make our /dist/plugins build script insert "-dev" on the plugin
info for packages it builds from branches.

2) Add code to Habari core to detect .svn stash files for branch
plugins, and display "-dev" in the plugin listing for those plugins.

I think developers would be willing to apply the necessary tags
manually by social convention, but the sheer effort would be anathema
to it happening in reality. So if we make it easier by doing the
above things (which seem comparatively simple and able to implement
once) then we all win.

Owen

[Owen Winkler]

Sean Coates wrote:
>
> The example in the wiki (http://wiki.habariproject.org/en/pluggable#provides) is:
> <provides>
> <feature url="http://wiki.habariproject.org/en/feature/podcast">podcast</feature>
> </provides>
> Does this mean that the "podcast" hooks can never change? What if we have "podcast2"? I guess I just don't understand.

My original idea for this was to use hook/API function signatures for
compatibility. So rather than having a single feature identifier to
represent a number of things, you'd add a bunch of hashes for the
entrypoints your plugin used within Habari.

Explaining how this worked seemed problematic.

So, it seemed better to have a convention that allowed plugin authors to
say that they implement something in a certain way, and characterize
that method with a single, descriptive, *documented* feature identifier.
These features are somewhat analogous to OOP's Interface idea.

If someone implemented podcasting in a completely different way,
offering a different set of functions, then they'd probably need
"podcast2". Or they could supplement the existing "podcast" feature
with the names of the features they add, like "podcast video".

Truly, "podcast" is a very abstract feature. More documentation should
be done on how these things would best work, he says as he returns to
watching TV.


>

> You seem to agree. What's your opinion on how to do this?

[Philip Olson]

I'm late to the game but have questions about plugin versioning. It
seems these definitions have changed over the months/years and still
contains confusion, and parts are being discussed now. So, while I am
_not_ proposing anything here, I'm hoping to help clarify the current
situation as specific parts. This is how I see it today (in practice):

a. Tags are used for releases. If something does not work, don't tag
it (true? maybe depends on tagging scheme?)
b. Trunk is for the latest development, which coincides with Habari
trunk
c. Version numbers live in the XML file, and do not contain Habari
version numbers. So, 1.0 instead of 0.7-1.0
d. Tags are version specific releases: So, a tag might be 0.7-1.0 but
not 0.7-1.x
e. A branch differs, so it might be: 0.7-1.x or 0.7-2.x but not 0.7-1.0
f. Versions like 0.1.1 or 0.1-alpha are discouraged, or perhaps even
illegal? Well, maybe 0.1.1 is okay?
g. Not sure if we'll use -dev in trunk, but it appears not (so far),
or maybe only the dist/build script will add this? or, both?
h. If trunk is "0.7" then there is no "0.7" branch, yet

I'm guessing at least one item above is incorrect, and a few are
probably debatable.

Regards,
Philip