Spree Upgrade - go live on v2.0.4 or move further to 2.1.0?

The current OFN 2-0-stable depends on 2.0.4, soon we will have this branch working and ready for testing.
The next release to production of this branch will be OFN v2.0.0.

This thread serves to make two decisions:

  • what spree version will OFN v2.0.0 depend on? we can go live with current spree 2.0.4 or continue to 2.1.0 before going live.
  • what strategy will we follow to reach spree v2.1.0? Even if we make OFN 2.0.0 run on spree 2-0-4 (see decision above), we will need to afterwards continue the spree upgrade to v2.1.0.

Facts and previous discussion

Spree v2.0.4 and v2.1.0 were released almost at the same time. Spree v2.0.8 for example, was released 4 months after both.
The spree upgrade to rails 4.0.0 happens in spree 2.1.

Luis: “Will we go to 2.1.0 or 2.0.8 afterwards? how do we decide?”

Maikel: “Is it easier to upgrade to 2.1 from 2.0.4 or from 2.0.8? You probably can’t answer that. If the patches contained in 2.0.8 are in later Spree releases as well, then we should go to 2.0.8 first. But if it goes into a different direction, we don’t need to take that detour.”

Pau: “They started working on 2.1 while 2.0 was still new?” (correct)
“We need to carefully investigate what you say. I bet that from 2.0.4 onwards it’s about backports from 2.1”

Luis: “in jan 2014 they released 1.3.5, 2.0.8 an 2.1.4”
“example way of working at the time: https://github.com/spree/spree/issues/3906#issuecomment-27236417”

Pau: “nice, you can see how on on Sep 16, 2013 they released 2.0.5 AND 2.1.0. From there they kept v1, v2 and v2.1 in sync. All released they same dates”
“yes, exactly, that comment is a great example.”

Luis: "so, 2.0.5 and 2.1.0 were released on the same day (one month and a half after 2-0-4)

  • 2.1.0 is 715 commits ahead of 2.0.4
  • 2.0.5 is 148 commits ahead of 2.0.4

I compared by commit message and from these 148 commits, only 29 commits are not in 2.1.0, I have checked 2 of them: one was present in 2.1.0 in a diff commit (the change is includes in 2.1.0 but in a commit with more changes, unlike the commit with the same change in 2.0.5), the other one was introduced in 2.2.0.
I guess we need to do this analysis for all the 29 commits.
if all of them are like these 2 I looked at, we can go straight to 2.1.0" (because what’s on 2.0.5 are only backports from 2.1.0)"

Tasks and Decisions

So, assuming most code in 2.0.5-2.0.8 are backports from 2.1.0 as it looks like from my quick analysis, we will most probably go directly from 2.0.4 to 2.1.0. 715 commits.

The original question: what version are we going live with?
I believe we will go directly live with the current version, so OFN v2.0.0 running on Spree v2.0.4.
And afterwards we can start the upgrade to 2.1.0.
Should we make this decision like this or should we investigate 2.0.5-2.0.8 a bit more?

Thank you for the summary. I agree with you. We should release OFN2 with Spree v2.0.4 and then work on the next Spree upgrade to 2.1.0.

Pretty good report @luisramos0.

I agree with the idea of aiming for 2.1.0 and running 2.0.4 live but I’d like to carefully understand potential risks of this approach. So yes, I think we should we investigate 2.0.5-2.0.8 a bit more.

What I like about running 2.0.4 is that we’ll see how this version of Spree and OFN play together. As a side note, we need to make extra sure we have the proper monitoring tools in place so we can fix runtime issues quickly. I expect quite a few in the beginning.

2.0.X series

By quickly skimming through I think 2.0.5 - 2.0.8 contains mostly fixes we’ll need too. We could simply get those fixes from 2.1.0 but I bet we’ll spend some time to make OFN work with that version (See the release note, particularly for core). Meanwhile, the bugs will need fixing.

So, I solution I see, is to upgrade to 2.0.X versions incrementally in master while we continue the Spree upgrade epic, now aiming for 2.1.0. I would treat this 2.0.X upgrades as regular bug fixes and include them in the usual release process. How does this sound? I’d like to avoid patchin our fork as much as possible.

the 2.1.0 release notes are ok, not too many things.
I dont think we should do both things at the same time as you suggest. I think we should either do 2.0.5 or 2.1.0 first.

“I think 2.0.5 - 2.0.8 contains mostly fixes we’ll need too”

I’d question this need. Right now I tend to vote for the direct jump to 2.1.0 only. I’ll investigate in more detail and report back.

1 Like

I guess it depends on how much time it will take to get to 2.1.0.

I have created the 2-1-0 branch.

Look what has just arrived in the OFN repo! :heart_eyes: https://github.com/openfoodfoundation/spree/blob/fa390dc9a10613e8cd6b87f2850e92df507e55a9/core/spree_core.gemspec#L34

The strategy was to use vanilla spree 2-1-0 and cherry-pick out commits from our 2-0-4 fork: 19 commits.

I’ve created this tech debt issue to get this going.

2 Likes