I believe I’ve mentioned in posts here on the blog as well as news entries on my main landing site (bc-programming.com itself) regarding my “maintainership” of a popular Bukkit Plugin, GriefPrevention.
I’ve fundamentally changed a lot about the way GriefPrevention works in the existing Development builds. Some people love the changes- others hate them.
Anyway, the reason I am making this post is because It’s getting a bit behind in terms of actually having a proper release- right now the dev builds usually work fine, though there are occasionally rather big issues in new features that cause data loss or ‘damage’ to claim data or other information that would definitely be a big blooper if they were to make it into a “sanctioned” release, or even a beta.
It would be easy to simply select an arbitrary development build, call it a beta, and upload it to the bukkit page as such. However, Personally I would guess that such an action should also include rather copious documentation and very much a re-consideration of pretty much everything written about the plugin so far. A lot of the existing pages written for the plugin will need to be changed extensively.
One of the issues raised is the ‘complexity’ of the newer configuration setup. IMO it’s not so much more complex as it is separated. If you ask me the previous configuration was more complex because settings that seemed unrelated would directly affect one another; and some settings didn’t even act as one would expect. The biggest issue with 7.7 and earlier was the refusal to properly deal with worlds and MCPC+ style servers. This was heckled along by the fact that the changes were insisted as being “impossible” or “requiring a rewrite”. I managed to coaz the changes in by simply changing how claims were loaded; this was also helped along by refactoring the configurations to work on a world-specific basis, which had the advantage of already separating functionality in a world-based manner and gave a basis on which to add new world-specific features.
The primary consideration once a Beta or even Release version of 7.8 is available is that the plugin needs to be reasonably well documented, both in terms of the plugin itself as used by consumers as well as in terms of the changes to the API itself. Another consideration is that it would be ideal to be available for questions as well as be watching the comments page like a hawk to answer questions and comments on the new release, since it’s likely that in promoting the dev build as a beta there would be numerous questions, problems, and general migration considerations being raised and a timely response to such questions would certainly be the ideal situation.