On Feb 11, 2008, at 8:56 PM, Mike Schrag wrote:
>>>> I'm sort of in a holding pattern and having second thoughts ...
>>>> If I commit, I also commit myself to a lot of work, because the
>>>> ant build portion is most likely going to break in a lot of
>>>> funky cases (who knows what people do in those ant files). I
>>>> don't know if I want to deal with it right now, so I'm just
>>>> putting it off. I'm thinking about just fixing a couple of the
>>>> notable regressions in the current one -- the double selection
>>>> of local + system frameworks, the P/Whatever error during
>>>> conversion, and the unique framework bug -- which incidentally
>>>> only doesn't happen to me because I have a custom NSBundle that
>>>> works around that problem.
>>>
>>> I like the idea of fixing these before going to completely new
>>> problems. Because the ones you mentioned are annoying (I stumble
>>> over them a lot at the moment, because I have to make so many
>>> changes here and there).
>>
>> +1
>>
>> Yeah, and this can be aimed at a new stable soon enough. I am keen
>> for the shake-up, but this seems like a sensible move prior to that.
> OK ... Here's what I'm proposing -- Comments welcome:
>
> Already done:
> * I just saved out patches for all my previous changes and I'm now
> rolled back to the current unstable trunk
>
> Proposal:
> * Fix these handful of regressions that showed up in 3.3 (listed
> above)
> * 3.3.2 is supposed to be out by the end of Feb, at which point we
> declare the unstable branch "stable"
> * Once we are declare stable on 3.3.2, I will modify my original
> classpath management code to use the CURRENT ant build system but
> with the NEW eclipse classpath management (= ant.* stays around,
> but management is much nicer and more fine-grain within Eclipse)
> and I'll commit that
> * After the inside-eclipse classpath system is tested and approved,
> that will move to the "stable"
> * After that moves to stable, the new ant build changes will go in
> * After the new ant build changes are stabilized, it will go to
> "stable"
Sounds like a good plan.
> * After that, possibly a bug bash? Vote for your most hated bugs,
> etc. I'd also really like to clean up the "zero state" of WO
> development -- smoothing the process for people just starting with
> WO development (I think this ultimately will help everyone by
> tightening the UI) -- if you have specific ideas for this, log them.
I like the zero state. I will think of some ideas. Preventing
people from making mistakes (like putting .wo components in the wrong
place) is one idea. Maybe auto creating a launcher?
> * Back to new stuff?
WOLips Kreskin Edition "Do what I am thinking, dammit!"
Chuck
--Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Wed Feb 13 2008 - 15:24:49 EST