fix(cli): version txt had a new line which it should not (#4233)

This commit is contained in:
Alireza 2024-06-17 10:17:38 -04:00 committed by GitHub
parent 729efb6d76
commit 097ef76655
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 24 additions and 20 deletions

View File

@ -118,19 +118,16 @@ This is typically where the latest development happens. Code that is in the mast
Each package is tagged with beta version numbers, and published to npm such as `@ohif/ui@3.6.0-beta.1` Each package is tagged with beta version numbers, and published to npm such as `@ohif/ui@3.6.0-beta.1`
### `release` branch - The latest stable release ### `release/*` branches - The latest stable releases
Once the `master` branch code reaches a stable, release-ready state, we conduct a comprehensive code review and QA testing. Upon approval, we create a new release branch from `master`. These branches represent the latest stable version considered ready for production.
This branch represents the latest stable version of the project that is considered ready for production. The code in this branch should be fully tested and vetted for release. Once the code in the master branch reaches a state where it's stable and ready to be released to users, For example, `release/3.5` is the branch for version 3.5.0, and `release/3.6` is for version 3.6.0. After each release, we wait a few days to ensure no critical bugs. If any are found, we fix them in the release branch and create a new release with a minor version bump, e.g., 3.5.1 in the `release/3.5` branch.
we do a comprehensive code review and QA testing. Once the code is approved,
we merge it into the release branch and tag a new release.
Each package is tagged with version numbers, and published to npm such as `@ohif/ui@3.5.0` Each package is tagged with version numbers and published to npm, such as `@ohif/ui@3.5.0`. Note that `master` is always ahead of the `release` branch. We publish docker builds for both beta and stable releases.
Note: `master` is always ahead of `release` branch. We publish both docker builds for beta and stable releases.
Here is a schematic representation of our development workflow: Here is a schematic representation of our development workflow:
![Alt text](platform/docs/docs/assets/img/github-readme-branches.png) ![alt text](platform/docs/docs/assets/img/github-readme-branches-Jun2024.png)

View File

@ -3,6 +3,8 @@ const { merge } = require('webpack-merge');
const path = require('path'); const path = require('path');
const webpackCommon = require('./../../../.webpack/webpack.base.js'); const webpackCommon = require('./../../../.webpack/webpack.base.js');
const pkg = require('./../package.json'); const pkg = require('./../package.json');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin; const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
const ROOT_DIR = path.join(__dirname, './..'); const ROOT_DIR = path.join(__dirname, './..');
@ -12,6 +14,8 @@ const ENTRY = {
app: `${SRC_DIR}/index.tsx`, app: `${SRC_DIR}/index.tsx`,
}; };
const outputName = `ohif-${pkg.name.split('/').pop()}`;
module.exports = (env, argv) => { module.exports = (env, argv) => {
const commonConfig = webpackCommon(env, argv, { SRC_DIR, ENTRY, DIST_DIR }); const commonConfig = webpackCommon(env, argv, { SRC_DIR, ENTRY, DIST_DIR });
@ -42,6 +46,10 @@ module.exports = (env, argv) => {
new webpack.optimize.LimitChunkCountPlugin({ new webpack.optimize.LimitChunkCountPlugin({
maxChunks: 1, maxChunks: 1,
}), }),
new MiniCssExtractPlugin({
filename: `./dist/${outputName}.css`,
chunkFilename: `./dist/${outputName}.css`,
}),
// new BundleAnalyzerPlugin(), // new BundleAnalyzerPlugin(),
], ],
}); });

View File

@ -4,7 +4,7 @@ import path from 'path';
async function editPackageJson(options) { async function editPackageJson(options) {
const { name, version, description, author, license, targetDir } = options; const { name, version, description, author, license, targetDir } = options;
const ohifVersion = fs.readFileSync('./version.txt', 'utf8'); const ohifVersion = fs.readFileSync('./version.txt', 'utf8').trim();
// read package.json from targetDir // read package.json from targetDir
const dependenciesPath = path.join(targetDir, 'dependencies.json'); const dependenciesPath = path.join(targetDir, 'dependencies.json');

View File

@ -15,9 +15,9 @@
"start": "yarn run dev" "start": "yarn run dev"
}, },
"peerDependencies": { "peerDependencies": {
"@ohif/core": "^3.0.0", "@ohif/core": "^{LATEST_OHIF_VERSION}",
"@ohif/extension-default": "^3.0.0", "@ohif/extension-default": "^{LATEST_OHIF_VERSION}",
"@ohif/extension-cornerstone": "^3.0.0", "@ohif/extension-cornerstone": "^{LATEST_OHIF_VERSION}",
"@ohif/i18n": "^1.0.0", "@ohif/i18n": "^1.0.0",
"prop-types": "^15.6.2", "prop-types": "^15.6.2",
"react": "^18.3.1", "react": "^18.3.1",

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 87 KiB

View File

@ -40,6 +40,7 @@ aren't as concerned with syncing updates, then follow these steps:
## Developing ## Developing
### Branches ### Branches
#### `master` branch - The latest dev (beta) release #### `master` branch - The latest dev (beta) release
@ -50,19 +51,17 @@ This is typically where the latest development happens. Code that is in the mast
Each package is tagged with beta version numbers, and published to npm such as `@ohif/ui@3.6.0-beta.1` Each package is tagged with beta version numbers, and published to npm such as `@ohif/ui@3.6.0-beta.1`
### `release` branch - The latest stable release ### `release/*` branches - The latest stable releases
Once the `master` branch code reaches a stable, release-ready state, we conduct a comprehensive code review and QA testing. Upon approval, we create a new release branch from `master`. These branches represent the latest stable version considered ready for production.
This branch represents the latest stable version of the project that is considered ready for production. The code in this branch should be fully tested and vetted for release. Once the code in the master branch reaches a state where it's stable and ready to be released to users, For example, `release/3.5` is the branch for version 3.5.0, and `release/3.6` is for version 3.6.0. After each release, we wait a few days to ensure no critical bugs. If any are found, we fix them in the release branch and create a new release with a minor version bump, e.g., 3.5.1 in the `release/3.5` branch.
we do a comprehensive code review and QA testing. Once the code is approved,
we merge it into the release branch and tag a new release.
Each package is tagged with version numbers, and published to npm such as `@ohif/ui@3.5.0` Each package is tagged with version numbers and published to npm, such as `@ohif/ui@3.5.0`. Note that `master` is always ahead of the `release` branch. We publish docker builds for both beta and stable releases.
Note: `master` is always ahead of `release` branch. We publish both docker builds for beta and stable releases.
Here is a schematic representation of our development workflow: Here is a schematic representation of our development workflow:
![Alt text](../../docs/assets/img/github-readme-branches.png) ![alt text](../assets/img/github-readme-branches-Jun2024.png)
### Requirements ### Requirements