Support/TikiWikiUpgrade: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 211: Line 211:
We should always strive to minimize the number of patches on SUMO that change Tiki but that we're not upstreaming for whatever reason; we all agree that having to maintain a set of patches that need to be re-applied for every future Tiki upgrade is not a good thing. Fortunately, the only real example of such a patch so far is our memcache implementation, which Tiki seems to want to implement differently. In other words, this is likely more of a theoretical concern than an actual one; staying in sync with Tiki between upgrades shouldn't be nearly as problematic as the graph suggests, as long as we're disciplined about upstreaming our patches.
We should always strive to minimize the number of patches on SUMO that change Tiki but that we're not upstreaming for whatever reason; we all agree that having to maintain a set of patches that need to be re-applied for every future Tiki upgrade is not a good thing. Fortunately, the only real example of such a patch so far is our memcache implementation, which Tiki seems to want to implement differently. In other words, this is likely more of a theoretical concern than an actual one; staying in sync with Tiki between upgrades shouldn't be nearly as problematic as the graph suggests, as long as we're disciplined about upstreaming our patches.


=Related=
=Decision=
[[Support/TikiUpstreamPlanning]]
We will go with the Upgrade option and upgrade to TikiWiki 4.1 or 5.1 in early 2010. See [[Support/TikiUpstreamPlanning]]
1,623

edits