Child pages
  • Sakai 2.8 Release Schedule
Skip to end of metadata
Go to start of metadata

Sakai 2.8.0 was released on 18 April 2011

Sakai 2.8.0 release date rescheduled

On behalf of the Release Management Workgroup and the Sakai 2 Technical Coordination Committee I am writing you to let you know that the Sakai 2.8.0 release date has been pushed back. This can be traced back to a scarcity of resources in the Sakai 2 ecosystem that resulted in slipped schedules (ie late beta and release candidate tagging), final hour testing and subsequently, outstanding blockers.

The anticipated release date is March 31st with the following milestones.

  • March 8/9 Release Candidate 2
  • March 22/23 Release Candidate 3 (as needed)
  • March 24-30 Prep for release
  • March 31 Release

To reach these milestones the following strategy is being employed:

  1. Blocker handling: Continue to triage the blocker list. If a ticket is not truly a blocker, downgrade it. In addition there will be regular communication with blocker assignees regarding progress on tickets.
  2. Tagging: Continue to cut QA tags every two weeks until blockers are eliminated. If an opportunity exists to cut a QA tag early, do it. When no blockers exist, cut an rc tag and prep for release.
  3. Continued testing: Encourage testing but do not allow shortfalls or delays in testing to hold up the release


1 April 2011 UPDATE:
On behalf of the Release Management team & Sakai Technical Coordination Committee I am writing you to let you know that the Sakai 2.8.0 release is now anticipated to occur in the 3rd week of April.   The release of IE9 highlighted some incompatibilities with the FCKeditor that the software could not be released with.  To address these issues, a patch has been written that will set IE to run in compatibility mode [1] and is the same approach the community took when IE8 was initially released. 
The anticipated  release date is April 13th with the following activities occurring:  
*  April 1                               Release Candidate 4 created
* April 8                                QA Testing through the 8th
* April  8-11                        Formal vote on release readiness by Sakai 2 TCC
* April  11                            Release artifact generated  
* April 11-13                       Release artifacts tested  
* April  13                            Aim to release Sakai 2.8.0 by  this date

2.8 Release Activities

The 2.8 Release Activities checklist provides a list of activities to help coordinate across the projects and to encourage communication to the community about the release expectations and progress. As with any schedule, adjustments to dates may be required

Start DateDue DateActivityActivity Description OwnerStatus & Notes
August 2010     
8/15/108/15/10Communication Communication on intended 2.8 Release changes are circulated to the community. This will include a list of enhancements as well as any tool inclusions or retirements. Seth Theriault (TCC Chair) or Megan May (TCC Vice Chair)Complete
 8/25/10CommunicationHighlevel timeline circulated to development community - important information like code freeze date, branching, tagging and intended release date are communicatedSeth Theriault (TCC Chair)Complete
6/15/108/25/10Tool Status Decision: Inclusion Decisions are finalized on promoting tools. Project teams begin work related to status changes and TCC Chair communicates decisionsSeth Theriault (TCC Chair)Complete
6/15/108/25/10Tool Status Decision: DeprecationDecisions are finalized on retiring tools. This can mean a tool is stealthed or that the code is 100% removed from the release. Project teams begin work related to status changes. Seth Theriault (TCC Chair)Complete
 8/25/10Upgrade DecisionDecisions on upgrades and additions to shared/common jar files and tools (e.g., java, maven, dbcp, spring, hibernate, tomcat) are completed. Seth Theriault (TCC Chair)Complete
      
September 2010     
6/21/109/17/10Information Gathering Project teams share tool and service plans and are encourage to start posting any documentation/specifications in the project's Confluence spaceMegan (TCC Vice Chair) Complete
 9/21/10Code Freeze (including kernel) at 23:59 UCTAll changes to code completed, including sakai.properties settings, appropriate default permissions, work related to tool status changes, kernel, database upgrade/conversion scripts, upgrades and additions to shared/common jar files and tools (e.g., java, maven, dbcp, spring, hibernate, tomcat) are completed. , etc. Project TeamsSome inclusions are still under review
 9/21/10Create 2.8 BranchBranch for release is cut from trunk. Changes after this point will require merging from trunk to the release branch. Anthony Whyte (2.8 Release Lead) Complete
 9/21/10QA Alpha tags Begin Begin tagging QA alpha releases off 2.8.x branch on a rigid 2 week schedule. Test plans are in progress or complete. Anthony Whyte (2.8 Release Lead) Complete
 9/21/10Alpha Tag 01 createdThe Alpha 01 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead) Complete (available 25 Sept 2010; schedule variance -4 days)
October 2010     
 10/5/10Alpha Tag 02 createdThe Alpha 02 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead) Complete (available 20 Oct 2010; delayed in order to include additional TCC-approved capabilities; schedule variance -15 days)
 10/19/10Alpha Tag 03 createdThe Alpha 03 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead) Complete (available 3 Nov 2010; schedule variance -15 days)
November 2010     
 11/1/10Tagging Decision: Move to Beta TagsRecommendation to move to beta tags Alan Berg (QA Director) & Anthony Whyte (2.8 Release Lead) Remain at alpha
9/21/1011/1/10TestingFunctional testers test the whole surface based off the functional changes document and test plans during Alpha tag phase Alan Berg (QA Director)  
9/1/1011/1/10Accessibility ReviewAccessibility Review of tools with Significant UI ChangesBrian Richwine (QA Accessibility Lead) 
 11/2/10QA Beta Tags BeginBegin tagging QA beta releases off 2.8.x branch on a rigid 2 week schedule.
- Final deadline for test plans
Anthony Whyte (2.8 Release Lead)  
 11/2/10Beta Tag 01 createdThe Beta 01 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead)  
 11/2/10String Freeze No more changes in UI text, so the Internationalization WG can create translations. Implementers can also begin updating their local documentation. Project Teams 
11/2/10Documentation / HelpHelp documentation has been updated and checked in so final translations can take placeProject Teams
IU KB (?)
9/21/1011/30/10Bug ReviewOutstanding bugs in JIRA are reviewed on project by project basis. Bugs that are no longer issues are closed, any bug that must be resolved for the 2.8 release (ie a Blocker) is marked as such and tagged correctly in JIRA. Anthony Whyte (2.8 Release Lead)  
 11/30/10Beta Tag 03 createdThe Beta 03 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead)  
December 2010     
 12/1/10Bug ReviewList of remaining 2.8 release Blockers from JIRA bug review is published to community. Anthony Whyte (2.8 Release Lead)  
 12/14/10Beta Tag 04 createdThe Beta 04 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead)  
January 2011     
 1/11/11Release Candidate Tag BeginsBegin tagging release candidates Anthony Whyte (2.8 Release Lead)  
 1/11/11RC Tag 01 createdThe RC 01 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead)  
 1/25/11TranslationsInternationalization WG has completed translations and they are checked in/merged to the 2.8. Language / region transalation leads 
 1/25/11RC Tag 02 createdThe RC 02 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead)  
February 2011     
 2/8/11RC Tag 03 createdThe RC 03 Tag is created and request to deploy to QA Server network is sentAnthony Whyte (2.8 Release Lead)  
 2/15/11Decision PointRelease Readiness Decision Point: The Sakai 2 Technical Coordination Committee will vote on whether or not the release is readySeth Theriault (TCC Chair) 
2/15/112/28/11Release Artifact TestingRelease artifacts are created and two weeks are allocated for testing/signoff. Alan Berg (QA Director)  
2/14/112/28/11CommunicationDraft announcement for mailing lists and Sakai Foundation websiteSakai Communications Lead 
March 2011     
 3/1/11Software Release Sakai 2.8.0 is released by the Sakai CommunityAll 

Notes

The attachment file contains a second tab with a number of communication & coordination activities that need to be slotted once the schedule framework is approved. 

  • No labels

3 Comments

  1. Notes from 7/22/10 release management meeting

    • Still need to determine scope. Anth thinks we need to figure out the project team plans ASAP so we can determine which of the 2.8 goals can be accomplished (ie fixing tools that don't compile in Java 6, registering events, ect)
    • Be more realistic to begin to produce alpha tags in September; after the code freeze
    • Include that mid Dec things slow down and do not pick up until Jan.
    • Kernel Freeze - should be same as code freeze.
    • Independent releases.   Clay/Nate give heads up on coming new functionality.   Evaluation work should take place during the month of Aug/Early Sept.  
  2. Personal notes to add to the meeting:

    • Help documentation:  The reference help documentation in English update should start at code freeze and end before its translation is due. Announcements of English updates ready per help documentation category should be sent to the i18n WG in order to smooth the translation process. I think we need a help documentation coordinator.
    • String Freeze: The string freeze should happen at code freeze to give more time to translators. I don't want 2.8.0 to be lacking translation as much as 2.7.0 is.
    • Translation: If string freeze happens at code freeze, translation of anything but the help documentation should start then with an announcement sent to the i18n/L10n WG. The WG is not the owner of the translations, each language/region/variant is responsible for its own translation. We should also ask for intend to translate or update the translation to the i18n/L10n WG.
    • Information Gathering: Maybe the TCC should own at least part of the Information Gathering. One of us should at least contact in our name all the code owners for code in 2.7 that is not under strict maintenance.
    • Code Freeze and Branch Freeze: How how we avoid anything being committed to trunk between the two? If we cannot, they should be synchronized at least from an svn point of view on a given svn external.
    • Indie Releases: Indie releases should be branched no later than the main branch freeze. All indie work should be at least ready at the same time as main code (Help documentation, String Freeze, Translation ...) and follow the same rules.
  3. Collected Comments as of 7/29/10

    •    Change Documentation
    o    AB:  Is there a particular format we'd like the changes documented in it
    o    Need to identify who defines format (AB) and who collects info (JF)
    o    AB:  would like test plans ready at the same time change documentation is done so this with help with coordinating testing
    o    JF:  Would like to know if this is going to be manual or if we're going to use
    o    Still need to determine scope. Anth thinks we need to figure out the project team plans ASAP so we can determine which of the 2.8 goals can be accomplished (ie fixing tools that don't compile in Java 6, registering events, ect)
    •    Tagging
    o    AW:   Mid-August Alpha tags I think are unrealistic
    o    RM Call:  Be more realistic to begin to produce alpha tags in September; after the code freeze
    •    Tool Additions and Removals
    o    Swinsburg:   dates are too early. 
    o    Swinsburg: Where are the list of tool changes?  
    ?    http://confluence.sakaiproject.org/display/MGT/Sakai+2x+Project+Planning+Goals
    o    AW:  As a starting point for debate regarding tool promotion:  : no new capabilities other than CKEditor (if Noah is game)
    o    AW:  As a starting point for debate regarding tool removals: Blogger, reports, warehouse; deprecate: profile (remove 2.9).

    •    Code Freeze and Branch Freeze:
    o    JF:  How how we avoid anything being committed to trunk between the two? If we cannot, they should be synchronized at least from an svn point of view on a given svn external.
    o    RM Call: Kernel Freeze - should be same as code freeze.
    •    Indie releases
    o    JF:   should be branched no later than the main branch freeze. All indie work should be at least ready at the same time as main code (Help documentation, String Freeze, Translation ...) and follow the same rules.  Maybe the first indie release artifact should be available before the branch freeze.
    o    Swinsburg: Need to add in indie and code freeze dates.  
    o    RM Call:   Clay/Nate give heads up on coming new functionality.   Evaluation work should take place during the month of Aug/Early Sept. 
    •    Translations/Help/String Freeze
    o    JF:  If string freeze happens at code freeze, translation of anything but the help documentation should start then with an announcement sent to the i18n/L10n WG. The WG is not the owner of the translations, each language/region/variant is responsible for its own translation. We should also ask for intend to translate or update the translation to the i18n/L10n WG.
    o    JF:  Announcements of English updates ready per help documentation category should be sent to the i18n WG in order to smooth the translation process. I think we need a help documentation coordinator.
    o    JF: The string freeze should happen at code freeze to give more time to translators. I don't want 2.8.0 to be lacking translation as much as 2.7.0 is.
    ?    MMM:    Is this realistic?    It doesn't seem so for 2.8 . . .  this might be something we aim for the next release.  
    •    Upgrade Freeze
    o    JF:   Need to identify impacted areas using maven versions:display-dependency-updates to identify impacted areas and have someone coordinate
    •    Misc
    o     Include that mid Dec things slow down and do not pick up until Jan.