Subject: Release date for GaiaBB and Release Policy
vanderaj
A.k.a.: Andrew van der Stock
Super Administrator
Lead Developer
Posts: 68
Threads: 41
Registered: August 26th, 2002
Member Is Offline
Location: Geelong, Victoria
Theme: GaiaBB Pro Grey
Mood: In the family again
posted on April 20th, 2010 at 12:31 AM
Release date for GaiaBB and Release Policy
I plan to release GaiaBB 1.0 on June 30, 2010.
This version will be roughly what you see here, but will also include a XS Moodle Authentication SSO Module. This will allow schools adopting the XS
School Server platform to have single sign on with the Moodle open courseware product. Students can then use GaiaBB as their forum rather than the
inbuilt Moodle forum.
Release Policy
There will be one major release each year, and four minor versions, released at the end of every quarter.
June 30, 2010 - GaiaBB 1.0 Long Term Support Release (Basic XS support)
- July 30, 1.0.1 Released (if required)
- Aug 30, 1.0.2 Released (if required)
- Sep 30, 1.0.3 Released (if required)
September 30, 2010 - GaiaBB 1.1 Release (XS to XS replication based upon NNTP)
- Oct 30, 1.0.4 and 1.1.4 Released (if required)
- Nov 30, 1.0.5 and 1.1.5 Released (if required)
- Dec 30, 1.0.6 and 1.1.6 Released (if required)
December 30, 2010 - GaiaBB 1.2 Release (Basic XO support for local XO installs)
- Jan 30, 1.0.7 and 1.2.7 Released (if required)
- Feb 28, 1.0.8 and 1.2.8 Released (if required)
- Mar 30, 1.0.9 and 1.2.9 Released (if required)
March 30, 2010 - GaiaBB 1.3 Release (Working on XS / XO enhancements)
- Apr 30, 1.0.10 and 1.3.10 Released (if required)
- May 28, 1.0.11 and 1.3.11 Released (if required)
- Jun 30, 1.0.12 and 1.3.12 Released (if required)
June 30, 2011 - GaiaBB 2.0 Long Term Support Release (Fully ready XS / XO deployments)
- Jul 30, 1.0.13, 2.0.13 (if required)
- Aug 28, 1.0.14, 2.0.14 Released (if required)
- Sep 30, 1.0.15, 2.0.15 Released (if required)
Sep 30, 2011 - GaiaBB 2.1 Release (Bring up forum features to meet competitor features)
- Oct 30, 1.0.16, 2.0.16, 2.1.16 (if required)
- Nov 28, 1.0.17, 2.0.17, 2.1.17 (if required)
- Dec 30, 1.0.18, 2.0.18, 2.1.18 (if required)
And so on and on. As you can see, there's only ever the Long Term Support (LTS) versions with security fixes and the last releases' updated. LTS to
LTS upgrades will always be supported, but minor to minor releases may have difficulty if the minor releases are far apart or ancient. Non-LTS
upgrades are on a best efforts basis as with all open source projects. We simply don't have the staff to test all those combinations.
The major release 1.0, 2.0, 3.0, etc will be supported for three years with *just* security patches. Major releases are highly stable, security
tested, and documentation complete. LTS releases are suitable for folks who run heavily modded forums, and will incorporate all the new features found
in the minor releases over the previous year, fully tested and documented. You will ALWAYS be able to upgrade to the latest version from a core stable
release for three years after the core release.
Minor releases 1.1, 1.2, 1.3, 2.1, 2.2, 2.3, etc will be supported for three months until the next release is made available. Minor releases add new
features from our "Enhancement" list on a continuous basis, so early adopters can try these new features out without waiting for an entire yearly
cycle. At the very least, new features will be tested, but documentation is on a best efforts basis. You will always be able to upgrade from a minor
release to the next minor release and the next major release (i.e a 1.1 board will be able to be upgraded to 1.2 and 2.0, but not necessarily 1.3, 2.2
or 3.0. The upgrade utility will tell you if you are ineligible to upgrade. Best efforts will be made to allow the upgrade to any new version, but we
can't guarantee it). Minor releases are suitable for forum owners who like to run with minimal mods and don't mind re-loading templates regularly.
Security fix releases are released as needed, such as 1.0.1, 1.0.2. To keep things simple, all security fixes will increase monotonically until the
product is retired. I will try to release security fixes on the last day of the month with as many security fixes as necessary at once, unless a
irresponsible disclosure forces our hand to release earlier.