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
probably
follow, 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
release
shortly 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 or
tomorrow. We'll then enter a code-freeze period, where we should
only fix
major 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 a
final 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.1
This also means if you have any pending change/fix that you'd
like to see
happening, 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]>
----------------------------------------------------------------
