[Seaside-dev] Seaside 3.0b1 release schedule

[John O'Keefe]

My 2c :-)

Software is a continually moving target and we each have to decide for our
own product (or have decided for us) when to wait and when to cut-and-run.
 My experience is that as long as we are clear on what we are delivering and
what we are not, there isn't a real problem.  We shipped VA Smalltalk V8.0
with Seaside 2.9a3+ and nobody seemed too bothered.  Our customers who are
interested in Seaside understand that schedules don't always match up with
reality.  Yes, it would be nice to say that V8.0.1 includes Seaside 3.0b1,
but if we decide to ship with something called Seaside 3.0a4+ (or 3.0b1-), I
expect our customers to have the same response as they did for V8.0.

I agree that if we are going to mess with EsEntryPoint, we should do it now.
 As far as the configuration UI, I guess I'm not the best judge of how
important it is -- I've learned how to navigate what we have (although I
remember it was pretty confusing to me when I started).

I am very grateful for all the work that the community puts into Seaside and
I don't want to push the community to do something that it isn't comfortable
with.  In the end, declaring 3.0b1 is a decision that Lukas, Julian, and
Philippe will make (with advice from all of us), and I am happy to live with
whatever they decide.

John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.


On Mon, Sep 21, 2009 at 7:03 PM, Michael Lucas-Smith <
mlucas-smith at cincom.com> wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20090922/5b17384d/attachment.htm