Richard Frovarp wrote:
Jörn Nettingsmeier wrote:
Richard Frovarp wrote:
Anyone against changing our Cocoon version in trunk to a stable
version of Cocoon? It would probably be good to start testing against
the version we will be releasing against.
i'd rather we freeze our cocoon external at the current revision. is
that possible? downgrading to the last release would be quite a step
back, and possibly invalidate much of the testing and measurements
that have already been done.
i agree we should protect our users from regressions in the 2.1 dev
tree, but going back a year or so seems an odd thing to do in open
source land...
It might be, but does anyone here keep enough track of Cocoon to be able
to do this?
what do you mean? to me, the only problem is that i don't know how to
"freeze" an external, or if it's even possible. but why does it need
extra cocoon insights?
We really should be against a stable revision. Otherwise, if
we just freeze we'll have to keep track of relevant patches to the
subsequent revisions and back port the patches to our revision. That
doesn't sound like fun.
true, but cocoon 2.1 commits are somewhat rare now, and afaict, there is
no strong inclination among cocoon devs to do global releases anymore -
their blocks have such different levels of activity that it's just not
very feasible.
the only reason we've seen frequent cocoon breakages in the past was
that the 2.1 brach shared code with the 2.2 trunk (somewhat
intransparently), so trunk commits tended to break 2.1. but iiuc that
has been fixed now.
maybe someone should ask around on cocoon-dev for recommendations...
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
