respect to this post , i expecting the best Ot
11.06.2009, at 19:26, Grégory Joseph wrote:
Hi,Sorry for taking so long to reply. It seems we need to clarify things a little, especially about what we call a "blocker" and what not.First off, I understand that those fixes were important for you. Heck, they're important to us.During development cycles, basically anything could be called a "blocker"; the most common reasons will be "we need feature X for project Y which has roll out with Magnolia n.m next month", "we need X to be able to implement Y in this or the next version", "feature Z of module M is planned for the next release, but needs X in Magnolia- core to work", and so on. Releases are guided by customer/user needs... and marketing. We're *trying* to be transparent and expose our plans upfront. We need to do it more. But you'll already find most of the plans document on the wiki, especially in the DEV space. We usually have a fairly flexible deadline for releases, or, at least, when starting to work on the next, the deadline isn't so lethal.But the closer we get to it, the more precise it has to be.These features or fixes (and countless others!!) didn't make it before the first RC. As soon as we're in "RC mode", the only reason code changes happen, or the only way any issue deserves the title of "blocker" is if this is a newly introduced bug that we've only just discovered (examples in the last RCs: fixes in activation have introduced a couple of other activation-related bugs - it went as far as the activation being completely broken in certain cases). Another case would be when we realise (too late) that a feature/fix we thought was completed actually isn't. This was the case with the multi-value change in the DefaultNodeData class that you've mentioned; multi-value support was actually introduced in the API in 4.0, and at that moment we had a module that started using it. While doing QA, we realized that it wasn't working properly in a corner- case. (when the multi-value property which has a single value is activated, it wasn't seen as a "multi-value property" on the public instance anymore). Yet another acceptable case is when we notice bundling issues. These are usually fairly hard to spot and fix on snapshots - there have been a bunch this time with the upgrade of a few maven plugins, etc.I don't want to play games, so, yes, there are certainly cases where we've cheated ourselves about this. Point is - these have discussed and agreed upon internally - so there is no surprise or unweighted risk. And you can ask anyone here, they'll confirm I'm pretty bitchy about this ;)We do these RCs to have a stable basis to do some QA. If other changes are introduced, this means more review and more QA work, which is both workload and risk which we can't afford at that moment.Your contributions are always appreciated, but we have to be fairly strict. On our end, we know we're not always as communicative as we could or should be (although in this case I believe the first RC was announced with advance, we had few pages going on the wiki). As much as I hate policing, I guess I'll have to publish those "rules" from now on. If fixes are SO urgent they *really* have to be included in between RCs, then at the very least, to avoid the waves of panic, report them on Jira - maybe with a reviewable patch - and ping the devlist, instead of silently applying them. (but don't be offended if we ask you to wait until the next release - the criteria above will still apply)On a more constructive note, is there something we could do to either facilitate your life if you have to live on patched versions until 4.1.1, or to make sure the "features or fixes you need but forgot to report until just now" show up in time ?Cheers, -g On Jun 3, 2009, at 3:32 PM, Fabrizio Giustina wrote:Hi Gregory, MAGNOLIA-2758 is IMHO definitively a blocker, and also MAGNOLIA-2653 is pretty critical.Ok for not committing enhancements but these have a reason for being in 4.1.fabrizio 2009/6/3 Grégory Joseph <[email protected]>:Hi all,If you hadn't noticed, we released 4.1RC2 last night. RC3 will probablyfollow, as we've found some bugs in the dms and stk updates.As such, I'd like to remind everyone this means we're in code freeze stage. Any non-blocker fix will be postponed to 4.1.1 (which we intend to releaseshortly after the final 4.1) Cheers, -greg On May 28, 2009, at 8:37 PM, Grégory Joseph wrote:Hi all, RC1 has been delayed a little; I'll start releasing it tonight ortomorrow. We'll then enter a code-freeze period, where we should only fixmajor blocking bugs. Cheers, -g On Apr 27, 2009, at 5:16 PM, Grégory Joseph wrote:Hi all,We're planning to release Magnolia 4.1 by the end of May. If all goes well, we'll have a first RC around the 22nd, and we'd love to push it to afinal the week after that.The current road map on Jira is irrelevant; we'll fix it a.s.a.p, but as of now, a good part of those issues will be postponed until 4.2 or later.Here's a more accurate roadmap, which we're currently updating: http://confluence.magnolia-cms.com/display/DEV/Roadmap+4.1This also means if you have any pending change/fix that you'd like to seehappening, it should come in before that. Cheers, Grégory Joseph Magnolia International Ltd. * Magnolia® - Simple Open Source Content Management ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> -------------------------------------------------------------------------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> -------------------------------------------------------------------------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> -------------------------------------------------------------------------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> -------------------------------------------------------------------------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
-- Leitung Bereich Entwicklung & Programmierung esense GmbH Leonhardsstrasse 37 CH-4051 Basel [email protected] +41 (0)61 271 35 01 http://www.esense.ch
smime.p7s
Description: S/MIME cryptographic signature
