>>> 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"
* 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.
* Back to new stuff?
ms
This archive was generated by hypermail 2.0.0 : Tue Feb 12 2008 - 00:29:44 EST