🔖(chore) bump release to 1.0.0-beta.0

[mbenadda]

This release indicates our intention to release richie 1.0.

Here are the core features that enabled us to reach this milestone:

• index the courses, organizations & subjects (now categories) in ElasticSearch from the DjangoCMS models;
• create course snapshots to keep a history of the versions of a course Page throughout its various course runs;
• add full text search queries to the course Search;
• handle facet counts for all our filters in course Search;
• develop plugins for all essential parts: courses, organizations, categories, people, licences...

As we prepare to release, here are some improvements and fixes still ahead of us:

• allow nesting of categories, to let users customize "meta" categories and build their own subtrees;
• finish integrating the missing pages and improve the sandbox environment;
• test and polish the use of richie as a django app / node dependency.

[mbenadda]

@jmaupetit I encountered a freaky bug with yarn on the CI that I was not able to reproduce locally despite numerous efforts. (I did not submit an issue there as I did not have reproduction steps).

To be short, yarn on the CI was installing an old version of @types/react inside @types/enzyme-adapter-react-16/node_modules. Of course, we still got the proper version in our node_modules. This broke the build as different versions of the typings for the same package cannot live together;

This is unexpected for two reasons:

• @types/enzyme-adapter-react-16 does not depend on @types/react. It only depends on @types/enzyme which itself depends on @types/react. It should therefore never have @types/react in its own node_modules as far as I understand it.
• We have a resolution in our package.json which normally forces everyone to use the common latest @types/react version. This is a yarn feature that is supposed to prevent this kind of issues (See some related discussion there Yarn is not deduping certain packages with * dependencies yarnpkg/yarn#6695).

After a lot of attempts to reproduce I used a "hack" to fix things: I just cleaned up the CircleCI Richie node_modules cache myself by running rm -rf. The cache without the incorrect dependency was then saved and is now used by all further builds which have the same yarn.lock file. At least until next Monday when we update dependencies and this cache is busted.

All this to say:

• doing this, I realized using a yarn.lock checksum for the cache entries makes way more sense than using a package.json checksum so I made this change.
• I decided not to investigate the issue further as I have spent too much time on this and we have other priorities than spending hours trying to reproduce a freaky bug. I'll look into it again if it pops up the next time we update the deps next Monday. If you're interested you can see a broken build here: https://circleci.com/gh/openfun/richie/32283.

If you agree with this I'll just merge this and make this damned release 😅

[mbenadda]

Another note: of course, I put the ci commit before the release commit; they're only shown in the wrong order because of the same old GitHub PR bug when you switch commits around by rebasing.

[jmaupetit]

I think you made the point: using yarn.lock file checksum makes way more sense 👍