[Seaside-dev] Seaside 3.0b1 release schedule

[Conrad Taylor]

Julian, I would recommend doing what's best for the project.  Thus, I  
wouldn't rush anything out to meet vendor timelines because they can  
simply download/import Seaside Beta when it's ready.  I say this  
because it would be a disservice to the quality of the project.  Some  
may be able to work around the issues but some may not.  In short,  
your decision(s) should benefit the project.

Just my 2 cents,

-Conrad

Sent from my iPhone

On Sep 21, 2009, at 2:49 PM, Julian Fitzell <jfitzell at gmail.com> wrote:

> 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
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev