[Deploying Sakai] [Building Sakai] Trunk: ui package proposal
slt at columbia.edu
Mon Nov 9 14:40:21 PST 2009
Anthony Whyte wrote:
> If we add velocity to the "ui" package for 2.7 the impact is
> greater. This is due principally to a short chain of
> velocity-courier-presence dependencies that must be confronted.
> Releasing velocity independently will require releasing both
> the courier and presence independently. People might not want
> to do this for 2.7.0. For myself, I think prepping these
> projects for an independent release no big deal but others may
> think it best to go slow.
[Cross-posting to the production list]
So that folks are aware, there are now several packages (kernel,
edu-services, Samigo, etc.) with "independent release" status
being readied for 2.7. While this approach offers some benefits,
I fear there is the potential for increased work for deployers
and more production-minded folks as a result.
Why? Because for every package that attains "independent release"
status, deployers who have local changes or patches or
differences now MUST build and deploy their own versions of the
affected package. As more and more "core services" packages are
created, it is more and more likely that deployers will have to
do this with as-yet-unknown effects.
I'll give you a simple example with Samigo (which is going
independent). Locally, Samigo is not known as "Tests & Quizzes",
but rather, "Test & Quiz". This requires 3 patches, one of which
is in the Help documentation. I now MUST build my own version of
Samigo to apply this type of change.
Perhaps we could slow the move to independent releases a bit in
advance of the main 2.7.0 Sakai release and see what effect, if
any, the new "independents" have on local deployment work.
More information about the production