Since you’re reading this, you’ve probably also read my post on package management for OS X, in particular the “anti-DLL hell” problem 3rd-party framework developers experience.
When I started Sparkle, it was a weekend-long project that I mostly did for myself. I never expected it to get this kind of adoption rate, so I didn’t really give any thought to scalability or anything, but now it’s a big issue. It’s silly to have this library being distributed a couple hundred times over, in different versions. Also scary.
With that in mind, I want to hold off on big plans for Sparkle 2 as a system-wide updating thing until I think more about a general system-wide package manager, as the latter would solve both problems.
To that end, I’m currently doing a major refactor of Sparkle 1.5 to keep it maintainable and extensible for the future. I’ll let you know how it goes.
Bear with me, folks.
The Conversation {3 comments}
Are you familiar with second system syndrome? “Merely” improving the guts of Sparkle 1.x with better version handling and differential updating would be a huge step forward with none of the philosophical conundrums attached. Properly encapsulated, all the code could be reused for Sparkle 2 once it gets going.
Yes, David, that’s exactly what I’m thinking. Throwing away the whole codebase is silly; it just needs major refactoring to be properly extensible.
Also unit testing.
An idea for deploying updates to the Sparkle.framework would be to simply use that Test App of yours to send the new frameworks out. I don’t know how feasible it really is, but I thought I’d just throw the idea out there.
Leave a Comment
You can follow any responses to this entry via its RSS comments feed. You can also leave a trackback if the inclination is there.