The future of the Bumblebee project is only limited by imagination and available time. So far, the developers have the following road map for where Bumblebee is going.... but if your favourite feature isn't listed here, please contact us as we're quite open to suggestions.

General Overview of Release Philosophy

Stable releases
Bumblebee is a system on which hundreds of people rely. Once a release is marked stable, it really should be that. Moreover, from then on, that series of releases should also be stable with only bugfixes and occasionally small, self-contained new features being added (in a way that won't break previous installations). Following the common open-source release numbering scheme, stable releases have an even number as their minor version number, for example 1.0.z, 1.2.z, etc. (download)
Developer releases
The only way to develop and test new features is by releasing code... "release early, release often". While the developer releases are marked as "unstable", we do believe that they are data-safe; they shouldn't corrupt your existing data and should be safe to use... there might just be a few pretty ugly bugs in them (which we hope you will report!). Of course, you always keep your data backed up, don't you. Developer releases have an odd number as their minor version number, such as 1.1.z, 1.3.z, etc. (download)
Database format
Upgrading to new database formats is a pain. Even with a cute GUI tool to help users with this, it's best avoided. The development plan is that the database format should be stable within each major release (i.e. the entire 1.y.z will have the same database format (or at least be backwards compatible: release 1.1.3 improved the handling of non-English (non-ASCII) characters significantly but that requires the fields in the database to be converted to UTF-8; this can be done safely)

Current plans

What is shown below are the current plans for (and in some ways the history of) the project. They are formulated with the idea of providing as many useful features as soon as possible and with the minimum number of changes to the database format.

Comments, criticisms, suggestions and ideas are most welcome.

 The Distant Future
   * full, user-configurable billing support included
   * can export invoices or statements of usage
   * can email invoices or statements of usage to groups
   * email users with notification of booking (ics attachment?)
   * email users a reminder that bookings are coming up (cron job)
 2.0 (new database structure)
   * heirarchical+fine-grained permission system 
     - groups of instruments
     - groups of users (groups? projects?)
   * group of instruments:
     - calendar displays
     - billing reports (UI improvement)
   * timeslot management improvements
     - require admin confirmation of booking on some instruments or for some timeslots
     - different booking slots for different types of user on same instrument (overlay calendar?)
     - unbooking an instrument causes an email to be sent to admin for some timeslots
     - unbooking an instrument causes an email to be sent to the unbook list for some timeslots
   * bring email templates into the database (+ interface to edit)
   * bring config file into database (+ interface to edit)
   * more reporting functions: 
     - future bookings by a user or group
     - summary of bookings for each user
     - summary of bookings for a set of instruments 
   * book instruments for weeks/months
   * better drop-down time listing for booking screen
   * improve timeslot config
     - validation on the timeslotrule input e.g. making sure every hour is accounted for
     - better UI for setting timeslots
   * improve HTML and PDF output (column widths algorithm)
   * internationalisation
   * PHP5 support
 1.0: Initial public release
   * permit admin user to masquerade as another user like 'su' to make bookings
   * rich calendar display with comments from booking or slot.
   * database backup/dump function
   * install script 
   * removal/hiding of unimplemented features (billing etc)
   * permit export of billing data to other external program
   * extended user testing
   * restrictions on when users can change booking details in place
   * per-instrument customisation of calendar views
   * inclusion of notes text on calendar views
   * permit customisable prefix on all database tables (allow db sharing)
   * can generate all data for booking system from within admin functions 
     (i.e. create users, set passwords etc all works sufficiently to be operable)
   * ability for local user to change password 
   * working time-slot verification on bookings
   * secure filesystem layout for ini files etc, ability to have ini files out of webserver tree
   * build in radius authentication (and other single-sign-on technologies as appropriate)
   * initial user testing
   * working time-slot display on caledar views
   * include instrument permissions system with instrument admin as well as system admin
   * able to edit complex many:many associations between users/projects/groups 
     and users/instruments.
   * display a calendar view of a selected instrument
   * create users and groups
   * first admin functions built on OO db+forms layer
   * remove billing features until rest of system matures sufficiently
 0.1: Initial public announcement
   * initial non-OO mock up to see feasibility
   * some user testing and expressions of interest sought

Last edited: Monday June 12, 2006

Valid XHTML 1.1 Valid CSS 2