[Seaside-dev] Seaside 3.0b1 release schedule

[Michael Lucas-Smith]

I know others feel it's important for Seaside to release a wonderfully 
perfect version.. but my concern is a different one.

I'm disinclined to rewind to 2.9a4 and call it 3.0a4, not when lots of 
work has been done between then and now. So if we release VW 7.7... what 
version of Seaside am I going to say ships with VW? "Seaside version 
somewhere between 3.0a4 and 3.0b1".
This is potentially more damaging than having a less than wonderful 
configuration system.

As Conrad points out, people can easily load up newer versions after the 
release, so as new versions are released we'll all be making them 
available. My hope is that we have a version we can point to and say 
"That's what's in VW7.7" which will help them understand if they need to 
upgrade to a newer version or not.

May be that can be 3.0b0, or 3.0b1, i don't know.. that's my concern and 
my 2c :)

Cheers,
Michael

Julian Fitzell 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
>
>