There is no version 2.8 of Mongo, they renamed that to 3.0 before release of 3.0. Just to provide a sense of the thought process other EPEL7 users might be going through here: I started researching this when I became aware that 2.6 was nearing upstream end-of-life (that is now happening today). I was aware of the recent major version upgrade of nodejs in EPEL7, so I assumed something like that was imminent. However, when I looked here: http://koji.fedoraproject.org/koji/buildinfo?buildID=802214 I saw that there have been several patches to EPEL6 MongoDB 2.4 since it reached its upstream end-of-life in March. So based on that evidence of prior commitment to maintaining MongoDB past end-of-life, I assumed that the intention was to keep on backporting patches to both 2.4 and 2.6. And I cancelled my red alert and stopped worrying about transitioning to the official MongoDB repositories. However it sounds like Marek, as the maintainer, is saying he doesn't have time to maintain 2.4 or 2.6. That's fair of course. Free is a very good price, and all that. (: For EPEL7, the upgrade seems fairly straightforward. 3.0 was really a marketing switch in the name of 2.8. I have experienced few problems moving projects between 3.0 and 2.6. Swapping the binaries and restarting is officially supported according to the documentation. The compatibility break pages are pretty short and there isn't much that would be in typical queries. For EPEL6, the upgrade is harder because you must first bump them to 2.6 and then to 3.0, there is no support for moving directly from 2.4 to 3.0. We could push out 2.6, wait a few weeks, and push out 3.0, but this would have a very unsatisfactory result for people who just don't happen to upgrade during those few weeks. They would get moved directly from 2.4 to 3.0 and the process would not work. There are also more bc breaks moving from 2.4, 2.6 and above are "pickier," notably a $set with no properties in the object will fail. https://docs.mongodb.com/v2.6/release-notes/2.6-compatibility/#driver-compatibility-changes In both cases, a proper announcement is necessary. A fair question is whether we should move to 3.0 or 3.2. The folks maintaining nodejs for EPEL chose to move from 0.10 to 6.x, skipping 4.x, because one bc break is better than two. So what I would suggest is this: FOR EPEL 6 * Announce our intentions. * IN THE MEANTIME: If any really major security fails occur between now and when we get this done, we grit our teeth and patch 2.4. * Publish a 3.0 package that refuses to install with an appropriate error message if it sees 2.4 (but is fine with seeing 2.6). * Simultaneously publish 2.6-for-upgrading package; the instructions for those with 2.4 point you to that package, and to this URL: https://docs.mongodb.com/v3.2/release-notes/2.6-upgrade/ * Users must manually install the 2.6-for-upgrading package, since the possible complexities of a 2.4 to 2.6 upgrade are beyond an automated post-install script IMHO. Notably: https://docs.mongodb.com/v3.2/release-notes/2.6-upgrade/#upgrade-auth-prereq * Once a user succeeds in that process, they can "yum update" painlessly to 3.0 like the EPEL7 people (see below). FOR EPEL 7 * Announce our intentions. I don't know how much notice is thought appropriate. The nodejs maintainers gave a lot of warning, but they also knew what was up way before end of life (: * Prepare a package for 3.0. It's a forced upgrade from 2.6. * Release it. If possible, print this URL after install: https://docs.mongodb.com/v3.2/release-notes/3.0-compatibility/ * Done (: Just my suggestion — I realize I just blew into town. Hope we can figure this out before the next CVE! _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
