You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Integration work related to Meilisearch pre-release
2
+
3
+
Every eight weeks, the engine team releases a new version of the Meilisearch engine. The last four weeks are the "pre-release time" where no new additions are made by the engine team, and release candidates (RCs) are done.
4
+
5
+
For each Meilisearch release, a central issue should be opened in the [integration-guide repository](https://github.com/meilisearch/integration-guides/issues). This central issue is an exhaustive list of the changes applied to the integration scope related to the future release of Meilisearch.
6
+
7
+
👇👇👇 Here is the template of the central issue to copy & paste. Replace the `TBD`. 👇👇👇
8
+
9
+
---
10
+
11
+
This issue gathers the changes related to the vX.Y.0 of Meilisearch that will impact the integrations scope.
12
+
13
+
📅 Release date: TBD
14
+
15
+
## TODO
16
+
17
+
### Before pre-release
18
+
19
+
-[ ] Define (with the help of PMs) which integrations should be updated to include the new features in the latest version of Meilisaearch. Most of the time, it will be tier #1 integrations.
20
+
Integration to update: TBD
21
+
22
+
### Pre-release
23
+
24
+
-[ ] Create branch by runnning [Octopus script](https://github.com/meilisearch/integration-automations/tree/main/octopus): only open branches for the integrations we choose to update + Kubernetes repository + Cloud provider repository (changing the version) + SDKs/integrations where we must update the test suite.
25
+
-[ ] Update integrations according to the new Meilisearch features (cf below which feature and how 👇)
26
+
⚠️ If possible, this step is done before pre-release, once the feature is ready thanks to the prototype released by the engine team
27
+
-[ ] TBD
28
+
-[ ] Update integrations having failing test suites with the new RC of Meilisearch
29
+
-[ ] TBD
30
+
-[ ] Add code samples for the chosen up-to-date integrations with the new version of Meilisearch
31
+
32
+
### Release day
33
+
34
+
-[ ] Release the integrations
35
+
-[ ] Merge the related PR in [K8s repository](https://github.com/meilisearch/meilisearch-kubernetes/pulls)
The objective of Meilisearch's Integrations Team is to **ease Meilisearch usage to as many developers as possible**.
3
+
The objective of Meilisearch's integrations is to **ease Meilisearch usage to as many developers as possible**.
4
4
5
-
Given this statement, **tiers** are nothing more than a __group of SDKs/integrations__ where the Integrations Team can fairly divide their attention. Unfortunatelyis not possible to keep all the SDKs 100% updated against the new Meilisearch features from Meilisearch releases all the time. The Integrations Team is a polyglot small team that maintains 30+ different integrations and tools, so it is humanly impossible to consistently meet the Meilisearch quality standards.
5
+
Given this statement, **tiers** are nothing more than a __group of SDKs/integrations__ where the Meilisearch team can fairly divide their attention. Unfortunately, it is not possible to keep all the SDKs 100% updated against the new Meilisearch features from Meilisearch releases all the time. The Meilisearch team is a small team that maintains 30+ different integrations and tools, so it is humanly impossible to consistently meet the Meilisearch quality standards.
6
6
7
7
The ultimate goal of introducing tiers is to allow the team to have more time to invest in new projects/integrations to impact even more users.
8
8
9
9
To measure the impact of an SDK, the data come from different places like [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html) and GitHub's stars, forks, and watchers.
10
10
11
-
It is worth remembering that this priority is just a concept introduced by the team that aims to give a **decision weight** before investing time in some issues of the SDKs. So it does not mean they will never work on feature requests from the bottom tiers anymore, but it says they will prioritize the top tiers most of the time transparently.
11
+
It is worth remembering that this priority is just a concept introduced by the team that aims to give a **decision weight** before investing time in some issues of the SDKs. So, it does not mean they will never work on feature requests from the bottom tiers anymore, but it says they will prioritize the top tiers most of the time transparently.
12
12
13
13
:warning: The team will still keep all officially maintained SDKs **working**. :warning:
14
14
15
15
## Tier #1
16
16
17
-
:warning: Managed by the internal team
17
+
👉 Priority of the Meili team
18
18
19
-
The SDKs in group #1 have absolute priority over the team's time. For example, issues are visited before issues are present in tier #2.
20
-
It is worth remembering that this does not mean open issues are addressed and fixed promptly. Every issue needs time to be understood/confirmed/worked on and consequently closed.
19
+
The Meili team ensures these integrations provide all the tools to use the features contained in the latest release of Meilisearch.
21
20
22
-
All new Meilisearch features that make sense for those SDKs will be available on the release day.
21
+
Issues and PRs from the community are frequently browsed by the team. If the community cannot be reactive enough, bug fixes and/or important enhancements are implemented by the Meili team.
22
+
23
+
It is worth remembering that this does not mean open issues are addressed and fixed promptly. Every issue needs time to be understood/confirmed/worked on and consequently closed.<br>
23
24
24
25
## Tier #2
25
26
26
-
:warning: Managed by the community & Internal team
27
+
👉 Mostly improved by the community
28
+
29
+
Issues and PRs from the community are less frequently browsed by the team but still watched regularly.
27
30
28
-
Tier #2 SDKs are the emergent ones. In any case, since they have a smaller audience than tier #1, the team will only spend the time required to keep these SDKs working and do the necessary maintenance code like fixing really important bugs.
31
+
Community work is crucial to improve the repository on a daily basis: suggest improvements, fix bugs and implement enhancements.
29
32
30
-
Only in urgent cases where, for example, the SDK is no longer working issues from the SDKs in group #2 prioritized over Tier #1.
33
+
Integrations in this group are prioritized only in **really critical** cases, and they are not going to receive active improvements or maintenance from the integrations team. If the community cannot be reactive enough and for **specific** situations, **critical** bug fixes and/or **critical** enhancements are implemented by the Meili team.
31
34
32
35
## Tier #3
33
36
34
-
:warning: Managed only by the community
37
+
👉 Fully improved by the community
35
38
36
39
The SDKs in group #3 have relatively low user adoption compared to groups #2 and #1. They are probably new or have a small community behind the tech stack in the first place.
37
-
As with tier #2, SDKs in this group are prioritized only in critical cases, and they are not going to receive active improvements or maintance from the integrations team.
38
40
39
-
This is a very special group because the Integrations Team really need help from the community here.
41
+
Issues and PRs from the community are not the team's priority, but they are still watched from time to time.
42
+
43
+
Community work is mandatory to improve the repository on a daily basis: suggest improvements, fix bugs and implement enhancements.
44
+
45
+
Integrations in this group are prioritized only in **really critical** cases, and they are not going to receive improvements or maintenance from the integrations team. If the community cannot be reactive enough, only **really critical** bugs are fixed by the Meili team.
40
46
47
+
## Deprecated
48
+
49
+
Depending on the reasons, integrations in this group tend to be archived at some point (a few months/years). The Meili team does not accept any enhancement in these repositories, even from the community.
50
+
51
+
Bug fixes have to be done by the community since the Meili team cannot afford to spend time on them.
52
+
53
+
We made our best to provide alternatives to this tools: check the related README of these repositories to get more information.
@curqui and @brunoocasali are the responsible for watching the repositories and ensuring they are relevant, detect and prioritize bugs/feature requests.
93
+
@curquiza and @brunoocasali are the main maintainers of the integration scope.
72
94
73
-
Also, they are responsible for releasing new versions of the SDKs.
95
+
They are responsible for:
96
+
97
+
- Releasing new versions
98
+
- Browsing the issues, which means:
99
+
- Redirect support questions to [Meili Discord](https://discord.meilisearch.com/)
100
+
- Answer and apply triage on issues
101
+
- Browse the requested feature requests: validate them, reject them, or ask for community's opinion.
102
+
- Browsing community's PRs and ensure they are reviewed
103
+
- Ensuring security fixes by merging bump of Dependabot
104
+
- Ensuring and follow [pre-release work related to the new Meilisearch version](./meilisearch-pre-release-work.md)
105
+
- Merge regularly Dependabot update to avoid outdated dependencies. We try to do it before releasing a new version of the integration.
74
106
75
107
## External contributors
76
108
@@ -86,6 +118,7 @@ Here is the list of the external collaborators that help us:
The method used is mainly manual and subjective, using previously collected data from the [telemetry](https://docs.meilisearch.com/learn/what_is_meilisearch/telemetry.html) and Github to generate the groups.
@@ -108,21 +141,8 @@ We also give more weight when we know a particular SDK has more Meilisearch Clou
108
141
109
142
PS: Other principles that are not written here may be used to move SDKs around if the team thinks it is relevant.
110
143
111
-
### When will the new features from a new Meilisearch release be released in the SDKs?
112
-
113
-
There is a [guideline](https://github.com/meilisearch/integration-guides/blob/main/resources/pre-release-week.md) the Integrations Team follows for every pre-release. Take a look at it to have more info.
114
-
115
-
Every pre-release has its central issue ([like this one](https://github.com/meilisearch/integration-guides/issues/251)). This issue describes every planned implementation the team will do in the weeks before the release. The community can expect that this plan will be achieved.
116
-
117
-
But if, for some reason, the team does not finish implementing on time, it still is the top priority to finish it before anything else. If only parts of the features are available on the release D-Day, the team will evaluate how long it will take to finish them. Depending on the integration tier, and the time it would take the team to finish, we will release the integration with the partial implementations. These are the delays we accept per tier before releasing:
118
-
119
-
Tier #1 = Release day + 1 day
120
-
Tier #2 = Release day + 1 week
121
-
Tier #3 = Release day + unlimited
122
-
123
-
So, if a tier #1 SDK is not fully ready on the Meilisearch engine release day, the user can expect a release in **any case on the following day**. Yes, __this release may lack some of the features planned initially__. Those features will be implemented as a top priority.<br/>
124
-
The same can happen with tier #2. If it is not fully ready, you can expect a release **a week after the release day**, and the remaining features will be implemented in the following weeks.<br/>
125
-
Tier #3**has no constraint** about having to be released in a particular amount of time.
144
+
### When will the new features from a new Meilisearch release be released in the integrations?
126
145
146
+
#1 integrations are up to date with the latest version of Meilisearch in the coming week of the [Meilisearch release](https://github.com/meilisearch/meilisearch/releases).
127
147
128
-
Remember that most new features will not be implemented in tier #3. Each repository will track those features individually as new issues after the pre-release time.
148
+
For other tiers, the features have to be implemented by the community. Issues are present in the related integration repositories. Once the PR is ready, the maintainers of the repository review and merge it to integrate it into the next integration release.
0 commit comments