Hi Thorsten,
Thorsten Scherler wrote:
Hi all,
I need to raise my concerns about the situation we have (again) on the
current trunk.
[Speaking purely as PMC member]
We raised the issue of branching when we will break the branch. The last
time this came up by dropping the extension of files. I thought we
agreed that if we break the trunk (like uuid is doing right now) we will
create a branch and merging back when it is stable and they are clear
instructions about updating homegrown modules to the new API.
However we just broke the trunk again and now the quota of side effect
questions are raising again. This cost a lot of time for this community.
We cannot afford this ATM!
The discussion about branching gave the impression that we like to be
able to break trunk every now and then, but under the condition of
regular releases. May I remind that number 1 faq is still "when will be
1.4 released".
Either we release before breaking trunk again or we *have to* branch
*before* breaking the trunk. ...or we will never ever release 1.4 at all
because all the extra work is loosing too much community.
I see your point here, but I think the urgency of a 1.4 release has
caused the trunk to be broken now. I believe that UUID's are the last
agreed upon hurdle to a 1.4 release (after testing and bugfixes). UUIDs
would break backwards compatibility and need to be in place for a release.
See the revolution branch as a side effect of this situation.
[Speaking purely as dev]
I cannot spend more hours to update my customers modules code against
the current HEAD. We far too often are breaking the current API that
custom code is not working anymore.
I feel your pain Thorsten, but also sympathize with the developer trying
to incorporate all of the required functionality for a 1.4 release. It
is an astonishing task to move 1.4 to uuid support.
This situation has come about by us using the trunk for production. The
trunk is far better (my opinion) than 1.2 and probably should have been
released w/o uuid,jcr,observation,etc last year at this time (as was the
schedule). There is always 1.6 which will hopefully be far better than 1.4.
As professional lenya dev with commit access I am writing custom lenya
related code and meanwhile enhancing the lenya code. When I write a
module it is normally against the current trunk back then.
The customer reviews it and has some changes. I now have the decission
between keep on using the original revision or updating the module to
use current HEAD. If I choose old revision then I cannot incorporate any
enhancements that HEAD brought or I can do while working on the module.
If I choose HEAD in the current situation, like I did, I am screwed.
Leaving me with a lot of more days to review all the modules I wrote. I
cannot do that anymore I have no time for it. I need a release to base
my custom modules on.
We need a release now.
I think we are all in agreement that a release is required. ;)
--Doug
salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
