[Deploying Sakai] [Building Sakai] Trunk: ui package proposal

Seth Theriault slt at columbia.edu
Tue Nov 10 07:55:00 PST 2009

David Haines wrote:

> I'm not sure what the problem is here. You have to patch and 
> build the project now anyway, you just have to patch and build 
> everything at the same time (which I don't see as a fundamental 
> advantage).  Is the issue mostly keeping track of what projects 
> have been patched and built when they aren't done in a single 
> mass build?

The main "problem" is that now managing a Sakai release is not a 
single release but multiple releases (Matt Jones made this point 
in a earlier response to the prod list) and that requires 
deployers to:

1) Be aware of this shift
2) Adapt their local processes to the new situation

Is this an impossible task? No, it is not, but it requires more 
work and possibly more intimate knowledge of how the new pieces 
of the puzzle fit together. For example, people who have changes 
to "independent" packages must deploy into a Maven repository in 
some way and that's a new semi-required step. Ditto for a 
required "independent" package like the K1 Kernel.

Another observation is that the semi-rapid movement from a 
monolithic release (2.5) to a separated release (2.6 + K1) to a 
more modular bundle (2.7 + K1 + "independents") may be leaving 
some people in the dust. That's my main thrust here.


More information about the production mailing list