Regular NPM releases? about data HOT 14 CLOSED

@chriseppstein , @frenic, @pkuczynski, @lahmatiy , we just released 1.1.1: https://www.npmjs.com/package/mdn-data. Please file bugs if you find any!

from data.

I released 1.1.0.

It's a minor release, as a new export was added and not a major (breaking) release as no existing exports or data structures have been changed.

I will try to release more often. If data is just updated without new added exports, it will be a patch release. Most of the current PRs look like that, so the next release might be 1.1.1.

from data.

We have #147 in review: when that lands it will be much easier to make npm releases.

We also have mdn/kumascript#343: when that lands we will have to get better at this, because MDN pages will themselves use the package (one of the problems until now is that they don't).

There are a couple of other reasons we're not maintaining mdn/data as well as we would like:

1. we don't have anyone in the MDN team dedicated to maintaining it (reviewing PRs, setting directions, making releases, ...)

2. we don't have a clear scope for the repo: this makes it more likely we will change the data in the future in a way that would break external consumers.

Compared with browser-compat-data, which has clear ownership and well-defined scope.

Can we help somehow?

Yes, probably! You already help a lot. What did you have in mind? In the very short term, feedback on #147 would be helpful. It would also be helpful to understand what your vision of mdn/data is - which parts of it you rely on (or want to rely on) for CSSTree. Also, we could add you as a collaborator, if you'd be interested, then you'd be able to help with management tasks too. No obligation though :).

from data.

I thought we would just go with something like this:

• 1.0.x: data got updated/added
• 1.x.0: substantial new data additions (new exports), other larger (but non-breaking) changes.
• x.0.0: breaking changes

As we have added new data in the "api" folder recently and that added new exports, I would release 1.1.0 now.
If we just change e.g. the CSS data, it would be 1.1.1, 1.1.2 etc. as next releases afterwards.

But I'm open to suggestions to do the versions differently. Compat data is now released once a week, but this repo has a bit less PR traffic. I agree we are a bit overdue with a release currently, though.

Feel free to vote on this comment or the one above that uses dates, so that I can see which versioning more people would like.

from data.

@Elchi3 Semver releases would be great -- I prefer this to the date-driven approach.

I'd expect a change like #61 to result in a major version bump. In general, I think this package should err on the side of releasing new major versions when data changes in a way that would require any downstream code changes to the website for existing data. This means that the major version number will probably go up pretty often and I think that's ok -- it can be hard with npm to prevent transitive dependencies from incrementing a minor release so it's best to be conservative there.

from data.

Semantic-release can solve this problem

from data.

Totally agree! Releases should be regular.
I though about version for the package. I think semver is not working well here, since data changing all the time. As a solution semver should indicate dictionaries format, and any change in data should produce a tag {version}-{publish-date}. For example, v1.0.0-20171031 or v1.0.20171031. Maybe tag should include time too to allow publish more than once a day (v1.0.0-20171031135722).
Another approach is to use incremental patch, like caniuse do. But with date version the tag is a more meaningful, it's easily to realise how old is your dictionaries.

from data.

I’d love to use this data in my own projects but at the moment I have to use a git submodule since the data is not regularly published to NPM. Seems like something like Travis could publish updated data on a regular schedule. The caniuse semver model seems to make sense to me. Humans could manually bump the version number and Travis could append the date suffix. ¯_(ツ)_/¯

Let me know if you all want contributions in this area.

from data.

It's been 6 months since the last (and single) release on npm. There are 44 commits that are not published yet.
Can we help somehow?

from data.

@Elchi3 Thanks for the 1.1 release. It's been 2 months since 1.1, and 13 commits since then, many of them with important fixes. Can releasing to npm become part of the standard workflow for this node package?

A suggestion: if the website was made to consume the publicly released npm package of this data, it would create a process where the normal workflow is also the process that ensures the released data is kept in sync with the website. 🤔

from data.

Releases of this package are blocked at the moment, after #156 was merged and contained some errors (#156 (comment)). There's an open PR to fix these issues: #191, but it needs review, probably from @lahmatiy among others, since he spotted the original errors.

from data.

If you need help with PR review and more frequent releases, I can volunteer:)

from data.

Thanks @pkuczynski . Review help is definitely welcome :). Better linting/validation, as in #196 and #172, is very welcome too. Making a release is quick and painless, but making sure the repo is in a releasable state is more work.

I'm hoping we will get better at making regular releases, but I'm conscious that we have said this before. As #132 (comment) suggested upthread, I would like MDN to use the packaged version too, then we will have to do better at this.

from data.

Sure! Just let me know how I can help :)

from data.