[WG: Sakai QA] [Management] Release proposal revisited

[Clay Fenlason]

Some responses in-line below.  A caveat about the language: 'tool
release' is a fair way to get started thinking about it, but we might
generalize that to 'module release.' I'll keep talking about tools for
now, though, since I think that makes it easier to digest:

On Tue, Sep 1, 2009 at 9:40 AM, Jean-Francois
Leveque<jean-francois.leveque at upmc.fr> wrote:
> If Forums is released with new features after 2.6 and before 2.7, how is
> this Forums release gonna be tagged?

If I'm understanding the question, I think the tool version numbering
needs to be entirely de-coupled from Sakai versions. Part of the point
would be to allow tools to make their own decisions about major and
minor releases, frequency of releases, etc. Fitting themselves beneath
an overarching numbering system would just get in the way.  So I think
this should be left to the respective team.

The cost of this, of course, is the care that would have to go toward
getting the right versions into a particular general Sakai release
cycle, especially where there may be cross-tool dependencies. Still,
that seems manageable. Tool release teams will also likely want to
provide documentation on which versions they have been tested against
and which they should be good for, given known API changes.

> Are we doing independent tools releases and building Sakai releases with
> kernel, API layer and chosen tool releases?

I'm not certain of the answer you're looking for here, but I think
you've described the general idea. Let me run through a couple points
with a little more precision, though. An independent tool release will
not be published by the Sakai Foundation in the way that general Sakai
releases are now, at least not yet. I'm thinking of them more like the
mature contrib tool releases (think of Nuno's recent release of
SiteStats 2.0). The main claim of an independent release is that it is
*internally* complete, consistent, and release-worthy as checked
against a known stable branch of Sakai code (i.e. a certain K1
version, etc.). Whether it introduces regressions in other components
(and vice-versa) will be a matter for general release QA, though
documenting a tool release should include a discussion of API changes,
known dependencies and associated implications. The big difference for
the general QA cycle is that documented, tested, and functionally
complete tags of certain modules will be taken as inputs rather than
the latest trunk at a code freeze date.

That's another way to think about this: as independent module releases
become more common, we're progressively shifting away from a global
code freeze of trunk, and letting modules iterate on their own
timeframes.  There will not be so much a big freeze date as a big
'bundle date,' if you will.  That is to say, at some point in time,
the pieces that are ready to go are tied together and tested as a unit
for a general Sakai release.  If you're not ready with a new version
for a new Sakai release, no worries, they can run with the old one,
and you can keep working on your tool releases for next time (or for
deployers that are prepared to pull it in after the fact).

> How easy will it be to upgrade a Sakai release only for chosen tools
> (use later tool releases than the one in the official Sakai release)?

This will depend in large degree, of course, on the tool itself and
the scope of change in a given tool release.  As mentioned above, the
tool release should document API changes, which other components it's
been tested against, what versions of Sakai it should work with, any
DDL scripts, etc.

> Is 2.6 ready for this?

At this stage I don't think any tools are going to try to start this
against a 2.6.x foundation.  But again, there's nothing stopping a
given team from doing so, it's just a question of the responsibility
they're prepared to take on.  By the same token, not all tools will be
taking on this responsibility during the next big release cycle. We'll
start with those that could most benefit from it, and which are ready
to manage themselves in this way.  If it goes well, the practice may
be extended.

> Will 2.7 be ready for this?

Again, the question is not so much if 2.7 is ready for this, it's
whether a given module/project leadership is ready for it.  We have
started some conversations with coordinated teams that might take on
this approach before and during the big 2.7 cycle, yes.  Right now I'm
trying to see if release teams can't be coordinated around
Forums+Messages (since those two share a single module), I think the
Samigo team is thinking about it, and perhaps Site Info as well. I'd
also encourage this for tools that are not part of the core code in
2.6 but would like to be considered for a future Sakai release: if you
get into the habit of putting out documented, tested releases you'll
be in a good position for community uptake, whether within a Sakai
release or deployed as an extra.

At the same time, Pete Peterson is mapping out a QA plan which
incorporates the idea of progressively including tool releases rather
than a single, global code freeze. Anthony Whyte is also working
through the details on the release management side of things, and I
expect we'll have documentation on how a team could manage its affairs
in this way, as far as svn and maven are concerned.  We're talking
about all these things at the weekly release planning meetings as
well.

~Clay

PS I'm going to post up some other notes that have been raised in
discussion on this, and try to have a FAQ available in Confluence.  On
my to-do list for the week.