> 1- There need to be a way to remove the patches for people that want
> to move on and use WO 5.4
I think the NS* class patches actually do get removed for 5.4 Wonder
builds, so I think we're good here ... Where it's a little more
complicated right now is with Ajax framework and the page caching
stuff. I'm not sure how to resolve that one without branching, but I
haven't spent too much time thinking about it either (probably when I
switch to 5.4 -- I'm hoping 5.4.1 might be the release where I switch).
> 2- I would like to see a better mechanism for patching so that we
> all know what is patched and I can work on getting those patches
> incorporated in the main line.
There are two types of patches that we do -- #1 is One is the really
early stuff, like NSArray, #2 is _NSUtilities.setClassNamed (or
whatever it is) to replace things like WOTextField, etc. I would
love to minimize/remove the #1-style, because these are just so
complicated/nasty/quasi-legal to maintain, but #2 may never go away.
I don't know what the strategy is long term. Obviously 5.4.1 is going
to come out, we can assume a 6.0 will also. This problem is only
going to get nastier for Wonder. I don't know if it's that we should
break up ERX more so we can phase in/out frameworks -- Like
ERXUtilities, ERXComponents, ERXPatchedComponents (I'm not sure what
it would be, just thinking "out loud" here).
Branching is just such a developmentally expensive process for us.
The other possibility is that 5.4.1 comes out (or 5.4.2, whatever
version it is that we are happy with) and we tag Wonder_5.3 and
everything beyond is 5.4 only. This really screws lots of people,
though, and decreases the value of Wonder. 5.2 was SORT of like this,
except that the changes from 5.2 => 5.3 where relatively small, while
the changes from 5.3 => 5.4 were reasonably large, and presumably 5.4
=> 6.0 could be MUCH larger. If someone were to step up and be the
Wonder 5.3 branch manager, like Apple does for Wonder 2.0, then
obviously we could continue to add new features to trunk and whoever
is responsible would port those patches back to 5.3. Basically I
MOSTLY only care about the version I myself am using, so once I move
to 5.4 (and all of our apps to 5.4), my brain stops caring about 5.3,
so somebody would need to take those reigns if we did the branch route.
Basically this is all just a bit of a mess. Apple certainly needs the
freedom to move the platform forward, and that is going to break
things, and that problem will only get harder; however, I think
consideration definitely needs to be given to things that break API
that really don't need to. We have just been spoiled for years now
not having to think about this, but we're going to have to figure this
out going forward.
> 3- I am working on a way to shorten Apple reaction time and that
> will reduce the need for patching
I think this is great if you guys can come up with a faster release
cycle, but there's definitely still the issue of certified/qualified
builds. I don't know if most people will be so cavalier about
grabbing the bleeding edge WO frameworks, but having options is not a
bad thing, certainly. It still presents ongoing problems for Wonder
-- if we fix something on Monday and that gets slurped into the core
on Tuesday, what does Wonder do now? People who aren't keen on
upgrading to WO 6.2.5 (which might have a very large changeset) might
be OK upgrading to Wonder 5.4.4206 to just get the little incremental
fixes.
> 4- I am very open to rethink the bootstrap class. I would like to
> get rid of those scripts and I would like the bootstrap class to be
> able to load in a jar i.e. being able to launch a WO app by double
> clicking it and get the internal jar to load correctly. If someone
> wants to work with me on this I am more than happy to share. And yes
> adding smarted loading mechanism is a very good idea.
The only thing I don't like about jar bundling frameworks is that it
makes deployment more obnoxious. For most of our apps, we don't run
separate standalone web servers, so we symlink WSR into the
framework. Jar bundling means deployment is always a two step
process, though. But this is more a complaint about deployment
process with WO being a little tedious (no nicely integrated tools
like Capistrano for WO) than specifically with jar bundling.
ms
This archive was generated by hypermail 2.0.0 : Tue Nov 13 2007 - 13:23:02 EST