This afternoon, rather quietly, I posted the first release candidate for Evergreen 1.2.0 on the Open-ILS.org download page. This is a big milestone for the project and for the developers. It’s also a big milestone for those interested in adopting Evergreen outside of PINES. The 1.0 series was pretty heavily skinned for PINES, with the images, rules, and default configuration, and new backend features were slow to be incorporated due to the pain of updating the database schema. The shiny new 1.2 series removes almost all traces of PINES-specific images and default rules, and contains many new backend improvements. It is also the first non-experimental release to include a significant amount of code not created directly by GPLS and PINES.
This is also the first release (experimental or stable) that does not include our application framework, OpenSRF, directly in the source. OpenSRF is now a proper dependency of Evergreen, and is free to evolve on its own and in its own time. It’s the most mature and heavily looked-over code produced for the Evergreen project, and has received the lion’s share of non-GPLS involvement. As time permits, we’d love to foster a community around OpenSRF — it’s definitely production-ready, and the ease of application development are, well, self-evident to this author.
We have many to thank for their help in getting to this point, not least of which are the amazing staff at GPLS and PINES, of course. Here follows a list of just a few of the contributors that have donated their time and expertise in recent memory, and deserve some special mention
- Dan Scott — Many of you know Dan in person or from his blog. He’s been busy evaluating different ILSs for Laurentian University, and in the process has managed to produce several patches, large and small, that make things generally better in Evergreen (and OpenSRF) land. He’s also been pushing us hard to focus on things like I18N and L10N. He’s been all over the wiki, working on the generic, Debian, and Gentoo installation instructions, and helping to keep ideas and plans from slipping through the cracks. And to top it all off he created one of the two live VMWare images running Evergreen.
- Scott McKellar — He introduced himself on the development list by mentioning a hobby of his (“nosing about in other people’s code”) and has proceeded to help us clean up large swaths of non-optimal code in OpenSRF.
- Don McMorris — The man is an installation-support-question-answering-and-wiki-documenting force of nature. Look for more of (and from) him in the future, to be sure.
- Jeroen Ruigrok van der Werven — While, like Scott McKellar, Jeroen has no current connection to the library world (he recently left a library, if memory serves), he has been donating his time and expertise to help us further simplify the installation process of Evergreen by reworking the compilation process to use GNU Autotools instead of our home-grown makefiles.
This is just a partial list — there are some 300 or so subscribers to both the general and development mailing lists, and I think we’ve heard from a good quarter of the dev list members. We have 32 wiki editors creating documentation for Evergreen, the majority of them from outside Georgia. There are too many people for me to remember in a blog post, that much is certain, but I’ll be combing the mailing lists and the wiki, and when 1.2.0 goes gold (the more testers and testing, the faster 😉 ) I will include a full list of contributors of documentation, code, and general help.
So, anyway, here it is, and thanks!
–miker