Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regular NPM releases? #132

Closed
chriseppstein opened this issue Oct 27, 2017 · 14 comments
Closed

Regular NPM releases? #132

chriseppstein opened this issue Oct 27, 2017 · 14 comments

Comments

@chriseppstein
Copy link

This data is released on npm, but has only been released once despite frequent commits and updates to the website. Can the process for updating the website also include releasing updates to the npm package? 🙏

https://www.npmjs.com/package/mdn-data

@iamstarkov
Copy link
Contributor

Semantic-release can solve this problem

@lahmatiy
Copy link
Contributor

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.

@Elchi3
Copy link
Member

Elchi3 commented Nov 1, 2017

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.

@chriseppstein
Copy link
Author

@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.

@meyer
Copy link

meyer commented Dec 4, 2017

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.

@lahmatiy
Copy link
Contributor

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?

@wbamberg
Copy link
Contributor

wbamberg commented Jan 19, 2018

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 :).

@Elchi3
Copy link
Member

Elchi3 commented Jan 23, 2018

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.

@Elchi3 Elchi3 closed this as completed Jan 23, 2018
@chriseppstein
Copy link
Author

chriseppstein commented Mar 27, 2018

@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. 🤔

@wbamberg
Copy link
Contributor

wbamberg commented Apr 3, 2018

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.

@wbamberg
Copy link
Contributor

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

@pkuczynski
Copy link
Contributor

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

@wbamberg
Copy link
Contributor

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.

@pkuczynski
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants