2.6 Release Planning-1 (20081008)

Time / Date 

Attendees: Peter Knoop, Megan May, David Horwitz, Linda Place, Adam (Marist), Jasmine (Stanford), David Haines, Zhen, Jean-Francois, Anthony Whyte

Kernel

Starting Discussion point: - Do we have a new release candidate? (1.0RC2?) Do we need to branch the kernel? What do we need to be considering or accommodating with the kernel relative to the 2.6.x branch and trunk?

Status of current Kernel version:   we are using a snapshot of kernel1.   Megan and David would like the kernel and core sakai build both against release artifacts so when it's built we are using the same code. 

What's the differenc between a snapshot and a fix version?

• snapshot - indicates code that is changing.  Maven will assume that the code can change at anytime and look for new code. 
• A fix # - maven will assume that this isn't going to change. 

The kernel rc could change as we progress from alpha tag to alpha tag but this will depend on fixes being merged in.

2.6 tag

Starting Discussion point:  What else needs to be done before we tag the first version of 2.6 for testing? Do we want to start with 2.6.0-alpha01, or are we confident that it is useable enough to call it a beta at this point? (I'm certainly don't think we are at the release candidate reliability level just yet.)

• Nailing down the kernel.   
• Will be doing alpha tags
• Do we change the version number in poms to match the svn version?  Traditionally when rutting QA and RC tags we've left the versionin at m2.   We have code from the release generation that can be repurposed.   
  Decision was to do this - it's a best practice we haven't been following up until now and elminates confusion.
• Discussion about developing artifacts once we reach an RC stage so folks working on contrib tools could see how their tools work with the release.  No clear answer here . . . Might be something to keep in mind for future releases since K2 is going to have significant changes.  
• Q: Division of responsibility?   Is the kernel team responsibility to generate the release of the kernel or is someone else going to handle this.   Peter thought Ian was going to handle this, but will check with Ian and investigate getting Anth and David involved.  Also, hashing out a long term proccess is important?   Need to work on this in conjunction with kernel team
  

Future Meetings

Starting Discussion point:  Do we need to change it, or does it still work well for all the key participants? If it doesn't work well for you, what times and days would be better? (Keeping in mind that mid-day Eastern US time seems to work the best for catching
European/African and American East Coast/West Coast participants.)

Meeting will be held at 10am eastern.  May look into changing the time when the time changes

Other

• Megan - at next meeting we will review the current schedule to see what updates and revisions need to be made (string freeze, RC dates, ect)