v5.17.3 #6168
v5.17.3 #6168
Conversation
m4theushw
requested review from
flaviendelangle,
alexfauquette,
joserodolfofreitas,
cherniavskii,
DanailH and
LukasTy
|
These are the results for the performance tests:
|
CHANGELOG.md
Outdated
|
|
||
| - [pickers] Add Icelandic (is-IS) locale (#6137) @flaviendelangle | ||
| - [pickers] Fix `themeAugmentation` and style overriding (#6156) @LukasTy | ||
| - [pickers] Fix `x-date-pickers-pro` theme augmentation (#6096) @LukasTy |
There was a problem hiding this comment.
| - [pickers] Fix `x-date-pickers-pro` theme augmentation (#6096) @LukasTy | |
| - [pickers] Fix `@mui/x-date-pickers-pro` theme augmentation (#6096) @LukasTy |
Co-authored-by: Lukas <llukas.tyla@gmail.com> Co-authored-by: Flavien DELANGLE <flaviendelangle@gmail.com> Signed-off-by: Matheus Wichman <matheushw@outlook.com>
Signed-off-by: Matheus Wichman <matheushw@outlook.com>
Signed-off-by: Matheus Wichman <matheushw@outlook.com>
| @@ -1,6 +1,6 @@ | |||
| { | |||
| "name": "@mui/x-date-pickers", | |||
| "version": "5.0.1", | |||
| "version": "5.0.2", | |||
There was a problem hiding this comment.
Time to do the shift?
| "version": "5.0.2", | |
| "version": "5.17.3", |
For example:
https://bestpractices.coreinfrastructure.org/en/projects/6293
There was a problem hiding this comment.
IMHO, I think that we already missed the possible version sync when moving from beta to stable.
Where
5.0.0-beta.7->5.17.1would have seemed somewhat logical5.0.1->5.17.3seems like a strange unwarranted version jump
Correct me if I'm wrong, but based on your screenshot, I don't see anything forcing to have synced versions number – we must have unique version numbers for every release..? 🤔
There was a problem hiding this comment.
I'll keep as it is but we can discuss about unifying the versions and do it in the next release.
There was a problem hiding this comment.
5.0.0-beta.7 -> 5.17.1 would have seemed somewhat logical
I think that it would have been ideal, but I also think that it's never too late to align the versions.
I don't see anything forcing to have synced versions number – we must have unique version numbers for every release
True, the rationale would be: simplicity, one release, one version for the npm packages. I think that it would also help us differentiate in the space from the alternatives. It would help sell that we provide a singe touch point, that developers don't install a standalone date picker, they install MUI X that has a date picker.
I wished we could use https://lerna.js.org/docs/features/version-and-publish#fixedlocked-mode-default but because of the unstable npm repository for new components, it seems that we can't.
There was a problem hiding this comment.
I think that it would have been ideal, but I also think that it's never too late to align the versions.
We could aim to have synced versions going forward from v6. Although, that sort of also means, that we would always need to release all the packages, even though they don't have any changes in them.
What about the x-license-pro package then – it doesn't receive frequent changes. 🤔
I wished we could use https://lerna.js.org/docs/features/version-and-publish#fixedlocked-mode-default but because of the unstable npm repository for new components, it seems that we can't.
Isn't our lerna.json config a bit incorrect?
Lerna docs state, that if we want to run lerna in independent mode, the version field should have this string for version instead..? 🤔
Well, if want to have all the packages in same repo and over time add new packages with their own (canary) lifecycle, it forces us to run in independent mode.
There was a problem hiding this comment.
that we would always need to release all the packages, even though they don't have any changes in them.
What about the x-license-pro package then – it doesn't receive frequent changes.
@LukasTy Oops, sorry for the confusion. What I was referring to with "ideal" or "same version"s is https://lerna.js.org/docs/features/version-and-publish#fixedlocked-mode-default 's behavior, which is different.
Isn't our lerna.json config a bit incorrect?
Interesting. I guess it depends. In MUI Core, we do https://github.com/mui/material-ui/blame/2be49496773b599a539e815f2e4e45c8bd9a484c/lerna.json#L4, it's a bit painful to have to set each version manually but there are quite some alpha packages, so it might still be less pain, than having to fix the version of the alpha packages:
On MUI X, we have fewer stable vs. unstable packages difference (zero right now), so I think a yes to all of these is simple enough:
There was a problem hiding this comment.
For the near future we will have cycles of having stable and/or canary releases, switching release strategy because of that wouldn't make much sense IMO.
I see only one thing in question which we should decide on—should we sync the stable version of a package coming out of canary towards stable channel with the version of another package in the repo already in stable channel.
With this question—it would implicitly mean the version sync of other packages as well.
IMHO, I would be in favour of sticking with the mui repository approach of different packages having their own version cycles and in turn not having empty releases.
One of the arguments for going with this—the developers should already be familiar with this approach of having different versions from the mui repo packages. 🤔
Even industry "giants" like babel are also going with a similar approach of having packages with their own release lifecycles.
One thing I think we should fix/adjust with the next release is the version field in lerna.json.
Should we align it with our release approach and change to independent with the next release @flaviendelangle @m4theushw ?
No description provided.