Upgrading Open Source Apps

[Elizabeth]

My colleague and I were having a discussion about this, and I wondered what your opinions on this was.

Usually when I install an open source app, I hack it up to make it my own. Then the question comes in when an upgrade is available, sometimes it's easily upgraded, sometimes not, depending on the hack and the app. So at what point do you break free from the base and keep what you've got? Like I said, I know it depends on the app but I'm struggling with that a bit now.. I want to completely re-do a portion of this app but I'm a bit worried about integrating upgrades later on. Should I just hack away and keep it mine, effectively breaking free from the source on which it's based?

Opinions anyone?

[goldbug]

Why not roll your own patches (diff "your" version with the standard version), so then, with only minor tweaks if any, you can patch each standard release to be your own custom edition?

[Elizabeth]

Shouldn't I worry about my patches and the official app patches colliding?

[piersk]

No more than you would do when hacking it apart anyway, surely?

[Elizabeth]

Well that's what I'm struggling with... traditionally my hacks have been official ones, with a few minor changes here and there, no biggie. But I'm really needing to hack up my zencart like the texas chainsaw massacre, and I'm kind of stuck.

Some of those guys use Beyond Compare (http://www.scootersoftware.com/) to sync files; I'm considering that option. Seems like a big pain in the arse though.

[goldbug]

In my opinion, if you've got a patch, that you've documented pretty well (what it does, what it touches/changes), it would only be a smidge more work to actually runn diffs on standard-release (your pre-patch versions) versions against the previous "standard" release, so you can tell what got changed, and if it affects your patch (assuming they don't give detailed changelogs with new releases). If you actually kept track of what files your patches affect (should), you could even automate the new version diffs to check your list of files affected by your custom patch, and alert you of possible conflicts, or just auto-apply if no conflicts are found.

I'm not sure there is a "clean"/"easy" way to do what you want :/ At least with rolling your own patches, if they aren't affected by changes in new standard releases/trunk, they should apply in milliseconds.

If you're looking for a visual diff/compare utility, check out Files Comparer (http://www.script-debugger.com/download/). It may not be the best or fanciest, but it's free.

[Sxooter]

I think it depends on what you're doing to modify it. If your modifications are natural upgrades, then it might be worth submitting a patch to the original project. You'd be surprised how often outside patches get added to open source projects. I've fixed / written a fair number of patches for db based apps to work on pgsql and most project leaders have been happy to have my patches to apply to their projects.

OTOH, customization is another issue. If you're customizing the program, then diffs are the way to go.

I only wish the people what hack phpbb knew about the diff and patch commands. Man, their hacks are a nightmare to add to phpbb. Even one is quite tough, adding more than one is nearly impossible.