[Seaside-dev] Seaside 3.0b1 release schedule

[Julian Fitzell]

On Sat, Sep 19, 2009 at 11:45 AM, Lukas Renggli <renggli at gmail.com> wrote:
>> How does everyone else who is using/developing 3.0 feel? What's still missing?
>
> I think the remaining issues for beta1 are not that critical (mostly
> configuration UI related).
>
>   http://code.google.com/p/seaside/issues/list?can=2&q=milestone%3A3.0b1
>
> I noticed that the debugger is beta2, is that correct? I personally
> find that more important than any of the other bugs tagged as beta1.
>
> Personally I don't have much time to work on Seaside the coming
> months, but I don't mind going beta. After all it is just a name tag.

Well, ok, I looked at the list of issues. First of all, I can't see
anything that is *not* tagged for b1 that should be, so that's good. I
moved one issue from b1 to b2.

I do think the debugger can wait until b2 because I doubt fixing it
will make it hard for people to update their images. It is a "known
issue" for the release.

Issue 405 would be nice to have done and isn't a huge amount of work,
but it's probably not the end of the world if we punt to b2.

The remaining two issues are the sticky ones.

Issue 454 (about entry point, parent, etc) really should be resolved
because it will make changes to a key hierarchy. I think the answer is
to merge entry point and request handler and I can do this in the next
few days if people agree.

Issue 263, which is kind of a catch all for a whole bunch of
configuration woes is nasty. On the one hand, we probably could just
about punt on this until b2; but on the other hand, I have horrible
visions of people deciding to finally try the new version once it hits
beta and getting hit by that config UI, not knowing how to add
filters, etc. It seems like a terrible first impression.

So I'm open to opinions on that. Do we rush out a beta to meet the
vendor timelines even if it leaves a worse first impression for users?
I'm leaning one way but I'll wait to hear what others say before
skewing the discussion.

Finally, if we do go beta, there are two other issues:

a) what are we holding ourselves to (ie. what are we promising not to
change/break/do)? We should define this so we have a firm response for
why certain changes will not happen until the next release.

b) what do we actually need to do to make a beta? Just a builder
release and an updated one-click? Some of the class comments on key
classes seem pretty out of data... are we ok with that?

Julian