[Prev] Thread [Next]  |  [Prev] Date [Next]

[habari-dev] Re: Habari Extras plugins svn Ali B. Thu Jun 25 02:00:34 2009

On Thu, Jun 25, 2009 at 11:09 AM, Michael Bishop <[EMAIL PROTECTED]>wrote:

> On Jun 25, 3:08 am, "Ali B." <[EMAIL PROTECTED]> 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

> > 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.


Ali B. / dmondark

To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev