Ahhh - April. Spring is in the air, and it's time to clean up shop a little IMO :)
I'd like to do the following as soon as we're able: 1. Release 1.2.2 2. Change our website to use a new content tool (see below) 3. Start in earnest on Shiro 2.x Here's how I view these things - feedback/discussion welcome: 1) We'll be able to release 1.2.2 soon. I've committed a decent amount of community-contributed bug fixes this week (thanks to everyone for those), and there's just a few more. Any other point-revision backwards and forwards binary compatibility changes should go in here. Anything that breaks backwards *and* forwards binary compatibility can't go in here. But this pretty much requires #2 since we'll need to update our site to reflect the release: 2) First thing's first: Apache has shut down the Confluence -> HTML -> prod server deployment pipeline, so we currently have *no* way to ship edited or new content to our website at the moment. That means we need to put something in place asap. We can't effectively release 1.2.2 without updating site content to indicate it has been released. Now, I know that Apache has created their new CMS, but I've found it a bear to work with. Here's an example: have fun setting up/modifying our site's templates when you have to deal with stuff like this: http://svn.apache.org/repos/asf/zookeeper/site/trunk/lib/view.pm I can't make sense of this stuff at all, nor do I want to dust off Perl, which I haven't touched in 10 years - to do it. As an alternative, and mostly because I needed something similar for work here at Stormpath, I wrote a simple command line program that has proven to be pretty powerful. We are now using it and it has been easily usable by non-technical employees (Apache 2.0 licensed): https://github.com/lhazlewood/scms It basically takes Markdown files (MultiMarkdown dialect mostly), renders them to HTML, and then merges that HTML with one or more defined HTML templates to control the look and feel. The templates are Velocity templates and has a flexible content model + configuration approach. It's basically the same effect as our Confluence-based setup, but even better: all content is now managed and versioned in version control, so we can accept patches, rollback, etc. I would now like to try this out for Shiro. I believe it is a more enjoyable experience writing content using tools most of us already know (Markdown and Velocity instead of Markdown + Perl and Django-inspired custom mechanisms). Because there is nothing in our SVN's 'cms' directory anyway, I'll add stuff there and show you how it works so you can try it out (if we don't like it, we just revert. Since there is nothing there now, it won't hurt anything). Feedback welcome. 3) 1.2.x has been pretty stable for a long time, and there are enough architectural inconveniences with Shiro (for devs and users) that I think it's time we tackle 2.x in force. I'd like to create a new branch of of trunk to ensure we keep what is there (should be nearly identical to the 1.2.x branch anyway) and use that for any related maintenance or 1.3 branch if that ever makes sense. We then start using trunk for 2.0 (alpha). Thoughts, feedback and comments are welcome by all. Best, Les
