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.

Sign up for GitHub

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

Jump to bottom

Merging master in release #124

Merged
merged 16 commits into from
Jul 28, 2020
Merged

Merging master in release #124

merged 16 commits into from
Jul 28, 2020

Conversation

dtassone
Copy link
Member

No description provided.

dtassone and others added 14 commits July 23, 2020 08:59
@dtassone
Release v0.1.62 (#95)
b096de0 
* v0.1.51

* fix demo app build

* v0.1.52

* v0.1.53

* v0.1.54

* v0.1.55

* v0.1.56

* v0.1.57

* v0.1.58

* v0.1.59

* add missing export

* v0.1.60

* v0.1.61

* hot fix for tsconfig conf

* fix mistypes on the package.json

* fix empty space with prettier

* v0.1.62

* fix lerna.json whitespace
@dtassone
fix resize issue (#96)
9451137
@dependabot-preview
Bump eslint-config-airbnb-typescript from 8.0.2 to 9.0.0 (#112)
cea0c08
@dtassone @oliviertassinari
Pagination refactoring (#100)
8cf1bd1 
* implemented server pagination

* rename pagination options, doc, prettier

* fix lint

* Apply suggestions from code review

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>

* change casing value in featureMode and remove apiref check

* added missing dep in useEffect

* fix broken suggestion code

* fix doc comments

* Apply suggestions from code review

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>

* Fix FeatureMode enum and remove useCallback in demo

* fix import order

* added namespace to function call to remove import

* remove useCallback and add react. to mdx code

* add concurrency in server pagination demo

* fix feature mode export

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
@oliviertassinari
[core] Use the classnames helper (#105)
44b7fcb
@oliviertassinari
[core] Batch small changes (#104)
ee4819f
@oliviertassinari
[docs] Improve the JSDoc (#106)
4481b72
@dtassone @oliviertassinari
rename events and add onHover event (#103)
e2abc33 
* rename events and added onHover event

* rename events and added onHover event

* fix onPageChange rename and merge

* Js doc improvements

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>

* added hover stories

* small fix and cleanup

* revert rename, back to onRowSelected

* refactor hover and click handlers

* refactor cellParams

* prettier

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
@oliviertassinari
[test] Add yarn deduplicate step (#107)
1865ee2
@dtassone @oliviertassinari
[DataGrid] Set default logLevel to warn (#117)
8606ef3 
* override default logLevel to warn

* rerun CI

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
@oliviertassinari
[test] Lint JSON (#108)
81d6c5a
@dtassone
Merging release back to master (#120)
051d016 
* v0.1.51

* fix demo app build

* v0.1.52

* v0.1.53

* v0.1.54

* v0.1.55

* v0.1.56

* v0.1.57

* v0.1.58

* v0.1.59

* add missing export

* v0.1.60

* v0.1.61

* hot fix for tsconfig conf

* fix mistypes on the package.json

* fix empty space with prettier

* v0.1.62

* fix lerna.json whitespace

* v0.1.63

* v0.1.64

* prettier lerna.json due to lerna
@dtassone
fix cellClassRule type, fix keyboard timeout, small refactoring (#123)
22b6f3c 
* fix cellClassRule type, fix keyboard timeout, small refactoring

* prettier fix

* add cancel RAF for focus if new event coming
@dtassone
Merge branch 'release' into master
8098ea8
@dtassone
Copy link
Member Author

Merging master in release. I will publish and deploy once merged

@oliviertassinari
Copy link
Member

oliviertassinari commented Jul 28, 2020 •
edited
Loading

Have you considered to release from master directly? Have you considered to push force master to the release branch?

@dtassone
Copy link
Member Author

Have you considered to release from master directly? Have you considered to push force master to the release branch?

I don't want to release from master as we can break things easily on this branch. And that way we can control a bit more when we release.
I can do force push but I thought it was nice to use a PR and track when we release...
It's our branching model
[Feature]=> [Master] => [Release] (tag and publish package from this branch) => [master] (we merge release back to master to get the version update)

@oliviertassinari
Copy link
Member

oliviertassinari commented Jul 28, 2020 •
edited
Loading

I don't know what's the best approach around handling release, some of the things I think are important:

  • We know for each pull request/commit, in which version it was released
  • We generate a human-friendly and detailed changelog people can read
  • As much as possible is automated, to remove room for mistake & stress
  • We leverage https://github.com/mui-org/material-ui-x/releases

A few tools we could leverage:

I know that @eps1lon started to work on release automation, but I think that it was put on hold.

I recall we had a debate around either we should have one tag/commit per package release or a single tag that bundles all the released packages.

@eps1lon
Copy link
Member

eps1lon commented Jul 28, 2020

I know that @eps1lon started to work on release automation, but I think that it was put on hold.

Because I don't want to have discussions about the version every time. I would be nice if we could recognize SemVer but we only mention it in name. And every time we actual do a release we have to go over what we personally consider "minor" or "major" or if it's "likely to break".

I repeat what I said before: Do what works best for you on this repository. There isn't a single right way to do things that should be repeated just in pursuit of "consistency".

@dtassone
Copy link
Member Author

I repeat what I said before: Do what works best for you on this repository. There isn't a single right way to do things that should be repeated just in pursuit of "consistency".

I definitely agree with this sentence :)

And I also believe that we need to improve our release process for X. The process is currently manual, but bear with us, we are still in early-stage with the project.

dtassone and others added 2 commits July 28, 2020 17:49
@dtassone @oliviertassinari
added keyboard doc (#125)
a9ca2f9 
* added keyboard doc

* Apply suggestions from code review

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>

Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
@dtassone
[DataGrid] Fix selection issue (#126)
c6bab0e 
* fix selection issue

* fix selection issue test
@dtassone dtassone merged commit b226105 into release Jul 28, 2020
@oliviertassinari
Copy link
Member

oliviertassinari commented Jul 31, 2020 •
edited
Loading

I don't want to have discussions about the version every time.

@eps1lon From what I understand, we could simplify the discussion by using https://www.conventionalcommits.org/. It would then come down to what's the correct commit message for each pull request.

Do what works best for you on this repository. There isn't a single right way to do things that should be repeated just in pursuit of "consistency".

I think that the pursuit of "consistency" is fruitless. It can only be the consequence of an objective or a tool to reach an objective. It should never the objective itself. For instance, consistency of the pattern of children?: React.Node forces us to question which approach is the best one and also remove doubts about which approach to pick.

I share some of what I think the strategy should be in #115 (comment) (the what and why). The key elements for treating the two repositories as a single entity:

  1. It forces the confrontation of conflicting points of view. I think that the best way to find the best approach is by resolving the opposite views people have on topics. There is something to learn. The sooner, the better.
  2. It forces us to hit reality. By deploying solutions that cover the whole scope of the problems we are facing, I think that we are making better decisions.
  3. It scales better. While having 1 person working on material-ui-x and 1 person working on material-ui allows us to bypass 1., this doesn't prepare ourselves to have 5 persons on each. At which people, contribute will frequently contribute to the two repositories. Treating the codebase as identical will then become an obvious necessity.
  4. DevOps is hard. We have experienced it first hand from the main repository, building the infrastructure to support the authoring of leading UI components is hard, we often have to build the tools for ourselves as nothing is available in the community (or of poor quality). We have a significant opportunity by not duplicating this effort.

I also think that once we get more than 10 people in the team, it starts to make sense to allow more explorations and short/medium-term divergences, as the potential ROI increases.

@oliviertassinari oliviertassinari added the release We are shipping :D label Jan 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@oliviertassinari oliviertassinari Awaiting requested review from oliviertassinari

Assignees
No one assigned
Labels
release We are shipping :D
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@dtassone @oliviertassinari @eps1lon