Overhauling -extras
mikelietz
trunks. With 0.7 potentially being a big release for themers, I assume
there will be some new functionality there soon that would make the
zips unusable for people not keeping current with HEAD.
This isn't the first time this situation has come up - this happened
prior to the 0.6 release as well, particularly with the plugins.
We've got /branches and /tags in all of the plugin and theme
directories, but their use is neither consistent nor frequent. In
discussions with ringmaster it has been suggested that we stop zipping
up trunk -- and could even abolish it altogether -- and use tags and
branches instead to make zips of releases and development.
For example, the twitter plugin:
Branches for 0.6 and 0.7 would be created.
For 0.6.x it is currently stable at version 0.12, so a tag would be
created, something like 0.6-0.12, and that could be zipped up as the
0.6 stable release. If more 0.6-compatible features are added to it,
they'd appear in the 0.6 development branch until tagged (as 0.6-13,
perhaps).
For 0.7 the new cache $keep should be used, so that would go in the
0.7 branch, and more development could continue without affecting
0.6.x users.
Plugins and themes that are not fully tested with, say, the current
release version would not be tagged until they are fixed (such as
photoblog). Those ones would only have a development version, and
wherever these are displayed (plugin directory to the rescue) would
need to indicate as such.
Such a system might sound complex, and will add a little complexity
for checking out and downloading the plugins, but some new best
practices should alleviate the former, and a plugin directory (which
is still being worked on) would make downloading the proper versions
easier and more reliable for users of all versions.
I'm willing to help with the moves (creating branches and deleting
trunks), but I'm sure there are details I've missed, or better
suggestions, before I start making major changes like this to the
repository. Any thoughts?
Owen Winkler
> Any thoughts?
I have a couple.
Yes, I think that development should happen in branches, not in trunk.
In this way we can prepare releases for different versions of Habari,
which will be more important when we start releasing major version
numbers where the API doesn't change.
Note that plugins should probably take on the same API-to-version number
characteristics of the core software. That is, API changes incite major
version number revisions, and feature additions that don't affect API
are minor versions. All bets are off on API stasis up until a 1.0
release. You know the drill.
I agree we should use the convention you suggested, but to perhaps clarify:
branches/0.6-0.x : This branch works with Habari 0.6, and houses
versions 0.1 to 0.100 (or whatever) of the plugin while it's in development.
tags/0.6-0.1 : This tag is for the 0.1 version of this plugin that
works with Habari 0.6.
tags/0.7-0.2 : This tag is for the 0.2 version of this plugin that
works with Habari 0.7. If version 0.1 of a plugin continues to work
with the next version of Habari, then the tag can be copied to the next
core version number, ala 0.7-0.2 to 0.8-0.2. The development branch for
the 0.2 version of the plugin would be copied from 0.7-0.x to 0.8-0.x,
and development in 0.7-0.x would cease.
These things become more important when we reach full Habari version
numbers. Our 1.x release of Habari should have plugins that use 1.x in
their branch names:
branches/1.x-0.x : This is the development branch for a plugin
targeting Habari 1.0 through 1.100 (or any minor version).
branches/1.x-1.x : This is the development branch for a plugin
targeting Habari's 1.x series, and it is internally API-stable.
tags/1.x-1.1 : This is the released tag for a plugin on Habari's 1.x
series, and has bug fixes or API-unrelated feature additions from the
plugins 1.x branch.
Note that the tags have full version numbers for the plugin version,
just like Habari has full version numbers for its released tags.
Using this release strategy, we can easily tell (and use automation to
discover) what the most recent version of a plugin is for each version
of Habari (if available), and whether there is an official release
and/or in-development version of the plugin in source control.
Concerning the issue of trunk: Yes, I think we should abandon trunk
development for plugins. If development happens in the branch, there's
no guessing at what version it is and what version of Habari's API it
targets.
That said, I think we should avoid an automated process that moves
everything from trunk to a branch. The reason I say this is because not
every plugin is compatible with the current Habari version, and there's
no way to tell if a plugin is being maintained or for what version of
Habari it might be targeted.
Part of the purpose of this is to better keep a handle on what versions
of plugins can work with what versions of Habari, so a wholesale move
seems unwise.
Manually verifying plugin compatibility and moving seems like a better
course to me.
Owen
mikelietz
On May 22, 4:44 pm, Owen Winkler <epit...@gmail.com> wrote:
> Concerning the issue of trunk: Yes, I think we should abandon trunk
> development for plugins. If development happens in the branch, there's
> no guessing at what version it is and what version of Habari's API it
> targets.
should be deleted?
> That said, I think we should avoid an automated process that moves
> everything from trunk to a branch. The reason I say this is because not
> every plugin is compatible with the current Habari version, and there's
> no way to tell if a plugin is being maintained or for what version of
> Habari it might be targeted.
have to be a manual process just to keep things straight and watch for
compatibility. We should manually verify that compatibility before
moving/tagging.
> Manually verifying plugin compatibility and moving seems like a better
> course to me.