| Server IP : 185.11.201.71 / Your IP : 192.168.7.18 Web Server : Apache/2.4.29 (Ubuntu) System : Linux tech-virtual-machine 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 User : tech ( 1000) PHP Version : 7.4.28 Disable Function : pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare, MySQL : OFF | cURL : OFF | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /comunica/app_ojos/frontend/node_modules/eslint-plugin-import/ |
Upload File : |
# Release steps 1. create a `release-[x.y.z]` branch from tip of `main` (or whatever release commit) ```bash git checkout main && git pull && git checkout -b release-2.1.0 ``` 2. bump `package.json` + update CHANGELOG version links for all releasing packages (i.e., root + any resolvers) In changelog for core plugin, normally leave [Unreleased] but update its link at the bottom to be rooted at the new version's tag, and add a link for the new version rooted at last version's tag. ```markdown [Unreleased]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.1...HEAD [2.0.1]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.0...v2.0.1 ``` becomes ```markdown [Unreleased]: https://github.com/import-js/eslint-plugin-import/compare/v2.1.0...HEAD [2.1.0]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.1...v2.1.0 [2.0.1]: https://github.com/import-js/eslint-plugin-import/compare/v2.0.0...v2.0.1 ``` Generally, don't use `npm version` for this because it creates a tag, which I normally wait until signoff from contributors and actually `npm publish`-ing to snap the tag. 3. create pull request from `release-[x.y.z]` into `release` branch I like this because it - lists all commits in the release - provides a commentary location to discuss the release - builds in CI and provides test results 4. iterate on feedback - handle other issues - merge more PRs - fix issues in changelog/docs 5. `npm publish` from `release-[x.y.z]` branch - don't forget resolvers! 6. tag commit (`v[x.y.z]`) - again, not forgetting resolvers, if needed (`resolvers/[name]/v[t.u.v]`) 7. merge `release-[x.y.z]` into `release` ( - ideally fast-forward, probably with Git CLI instead of Github 8. merge `release` into `main` Done!