1,623
edits
MarcLaporte (talk | contribs) 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. | ||
= | =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]] |
edits