Skip to content

Commit a175ec7

Browse files
lukashornychlukashornych
authored
Merge pull request #434 from FgForrest/dev
New Year's Update Release
2 parents a13d632 + 0d613d3 commit a175ec7

File tree

184 files changed

+10894
-4358
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

184 files changed

+10894
-4358
lines changed

‎.github/workflows/ci-master.yml

+3-3
Original file line numberDiff line numberDiff line change
@@ -41,11 +41,11 @@ jobs:
4141

4242
- name: Resolve new release version
4343
id: release_version
44-
uses: codacy/git-version@2.7.1
44+
uses: lukashornych/semantic-calendar-version@v1.1.3
4545
with:
4646
prefix: 'v'
47-
minor-identifier: 'feat'
48-
major-identifier: '(breaking)' # this should be placed somewhere in the commit message like "feat: (breaking) some message"
47+
year_switch_mode: 'OnMinor'
48+
minor-identifier: '/feat(?:\\([^)]+\\))?:/'
4949

5050
- name: Setup Java JDK
5151
uses: actions/setup-java@v3 # setup JDK 17 for building

‎.idea/GitLink.xml

+6
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

‎.idea/swagger-settings.xml

+6
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

‎docker/build.sh

+1-1
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@ else
4747
fi
4848

4949
echo "Tagging as: $IMAGE"
50-
docker buildx . \
50+
docker build . \
5151
--pull \
5252
--platform linux/amd64 \
5353
-t "$IMAGE" \

‎documentation/blog/en/01-origins-of-the-evita-db.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: The origins of the evitaDB
33
perex: Our company set foot in the e-commerce world around 2010. By that time we were in web development for more than 10 years, starting even before the .com bubble.
4-
date: '2022-01-12'
4+
date: '12.1.2022'
55
author: 'Ing. Jan Novotný'
66
motive: assets/images/01-origins-of-the-evita-db.png
77
---

‎documentation/blog/en/02-designing-evita-query-language-for-graphql-api.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: Designing the Evita Query Language for the GraphQL API
33
perex: In evitaDB (like in many other databases), in order to get any data, you need to somehow ask which data you want. The GraphQL language is, however, specific and needs a specific syntax.
4-
date: '2022-01-12'
4+
date: '12.1.2022'
55
author: 'Lukáš Hornych'
66
motive: assets/images/02-designing-evita-query-language-for-graphql-api.png
77
---

‎documentation/blog/en/03-choosing-http-server.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: Choosing HTTP server for evitaDB
33
perex: We plan to provide several ways to communicate with evitaDB clients. For that we needed some universal HTTP server that would serve at least most of the requests.
4-
date: '2022-06-17'
4+
date: '17.6.2022'
55
author: 'Lukáš Hornych, Jan Novotný'
66
motive: assets/images/03-choosing-http-server.png
77
---

‎documentation/blog/en/04-blazing-fast-integration-tests.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ title: Thousands integrations tests under 30 seconds? Yes, you can.
33
perex: |
44
A fast test suite is a critical aspect that motivates developers to write more tests and run the suite frequently.
55
The ideal test suite should finish in a matter of seconds or low units of minutes.
6-
date: '2023-03-25'
6+
date: '25.3.2023'
77
author: 'Ing. Jan Novotný'
88
motive: assets/images/04-blazing-fast-integration-tests.png
99
proofreading: 'needed'

‎documentation/blog/en/11-we-are-changing-versioning-scheme.md

+61
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
---
2+
title: We are changing versioning scheme
3+
perex: |
4+
I have always used the semantic versioning (SemVer) scheme for my projects. However, after discussing with my friend
5+
Lukáš Hornych and conducting further research with the team, we have decided to change the versioning scheme for
6+
evitaDB. The new scheme will be a Calendar Versioning. If you are interested in following our debate, read on.
7+
date: '14.1.2024'
8+
author: 'Jan Novotný'
9+
motive: assets/images/11-versioning-scheme.png
10+
proofreading: 'done'
11+
---
12+
13+
[Semantic Versioning](https://semver.org/) promises that your users can think about the impact of upgrading to a new
14+
version of your software. But is this really true? There are numerous articles that argue otherwise - I'd recommend
15+
[this discussion on Hacker News](https://news.ycombinator.com/item?id=21967879) and especially
16+
[this blog post](https://sedimental.org/designing_a_version.html).
17+
18+
SemVer brings interesting psychological factors into play. Far too often we see libraries with dozens of minor releases
19+
that never reach version 1.0. Why not? Maybe the author is afraid to commit to a stable API. Maybe the production
20+
release looks like too much responsibility. I fell into this trap myself - I was avoiding the 1.0 release until
21+
I screwed up and while testing the automatic release on GitHub, I accidentally released version 10.1 instead of 0.10.
22+
And since Maven Central (for good reasons) does not allow to [delete artifacts](https://central.sonatype.org/faq/can-i-change-a-component/),
23+
we were stuck with it. You might not think this is a big deal, but there are a lot of projects that have fallen into
24+
this trap, including pretty big names like [ReactNative](https://reactnative.dev/versions),
25+
[Elm-Language](https://elm-lang.org/news), and there's even a dedicated [website](https://0ver.org/) that tracks
26+
(or tracked) projects with zero versioning.
27+
28+
On the other hand, there are projects that very quickly increase the major version number to make themselves look more
29+
mature or up-to-date, or maybe just because they "don't care" about backwards compatibility! One of the most famous
30+
examples of the versioning battle was the [Chrome vs. Firefox battle](https://sedimental.org/designing_a_version.html#case-study-chrome-vs-firefox)
31+
for the most significant version number. So - if the major version is more about marketing than actual API stability,
32+
should we even care about it?
33+
34+
The compatibility guarantee is also a very tricky thing - if your project is popular enough, any change in it that
35+
somehow affects its behavior will [break someone's code](https://xkcd.com/1172/), even if the API stays the same.
36+
You will never be able to anticipate other people's expectations and assumptions.
37+
38+
There are also very good and balanced [defenses of the SemVer idea](https://caremad.io/posts/2016/02/versioning-software/)
39+
that we considered, but in the end we decided to go with calendar versioning, specifically the `YYYY.MINOR.MICRO` variant,
40+
for the following reasons:
41+
42+
1. no matter how hard we try, we will never be able to guarantee backwards compatibility - unless we have a very
43+
thorough test suite that covers all possible use cases, which evitaDB does not and probably never will have (let's be
44+
honest)
45+
2. we commit to trying to maintain backwards compatibility, and if it is knowingly broken, we will mark the release
46+
with a "breaking change" label (we already do this at the issue level), and once the project gets out of the
47+
"pre-release" stage, we will try to consolidate critical changes into larger milestones.
48+
3. if only the `MICRO` part changes, you can rest assured that the only changes in the build are fixes that are intended
49+
to be backward-compatible.
50+
4. if the `MINOR` part changes, it means there are new features - you should always check the release notes to see
51+
what's new and whether they contain breaking changes or not.
52+
5. you should always have your own test suite to verify that the new version works for you - if you don't, you shouldn't
53+
update the library anyway
54+
6. the `YYYY` part changes automatically with the first new `MINOR` release of the year - since our library is
55+
BSL-licensed, you can easily guess if the library you're using is still BSL-licensed or has already transitioned to
56+
Apache License 2.0.
57+
7. the `YYYY` part also helps you to see how old the version you're using is and easily identify whether we provide
58+
security updates and fixes for it or not (if we ever come up with such an offer).
59+
60+
So CalVer makes sense for us and we'll see how it goes. We will be releasing the first version with this schema in
61+
the next few days.

‎documentation/blog/en/assets/images/11-versioning-scheme.full.png

1.36 MB
Loading

‎documentation/blog/en/assets/images/11-versioning-scheme.png

114 KB
Loading

‎documentation/publishing/root.cz/03-query-basics/example-query.evitaql

+19
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
query(
2+
collection("Product"),
3+
filterBy(
4+
attributeEquals("status", "ACTIVE"),
5+
attributeGreaterThan("battery-life", 10),
6+
or(
7+
attributeIs("validity", NULL),
8+
attributeInRangeNow("validity")
9+
)
10+
),
11+
orderBy(
12+
attributeNatural("orderedQuantity", DESC)
13+
),
14+
require(
15+
entityFetch(
16+
attributeContentAll()
17+
)
18+
)
19+
)

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.evitaql

+6
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
query(
2+
collection("Product"),
3+
require(
4+
attributeHistogram(20, OPTIMIZED, "width")
5+
)
6+
)

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.evitaql.json.md

+43
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
```json
2+
{
3+
"histograms": {
4+
"width": {
5+
"buckets": [
6+
{
7+
"occurrences": 1291,
8+
"requested": true,
9+
"threshold": 15.90
10+
},
11+
{
12+
"occurrences": 210,
13+
"requested": true,
14+
"threshold": 97.92
15+
},
16+
{
17+
"occurrences": 1876,
18+
"requested": true,
19+
"threshold": 179.94
20+
},
21+
{
22+
"occurrences": 531,
23+
"requested": true,
24+
"threshold": 261.96
25+
},
26+
{
27+
"occurrences": 2,
28+
"requested": true,
29+
"threshold": 343.98
30+
},
31+
{
32+
"occurrences": 1,
33+
"requested": true,
34+
"threshold": 426.00
35+
}
36+
],
37+
"max": 508.00,
38+
"min": 15.90,
39+
"overallCount": 3911
40+
}
41+
}
42+
}
43+
```

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.evitaql.string.md

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
```md
2+
width: [15.90 - 97.92]: 1291, [97.92 - 179.94]: 210, [179.94 - 261.96]: 1876, [261.96 - 343.98]: 531, [343.98 - 426.00]: 2, [426.00 - 508.00]: 1
3+
```

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.graphql

+21
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
{
2+
queryProduct {
3+
extraResults {
4+
attributeHistogram {
5+
width {
6+
min
7+
max
8+
overallCount
9+
buckets(
10+
requestedCount: 20
11+
behavior: OPTIMIZED
12+
) {
13+
threshold
14+
occurrences
15+
requested
16+
}
17+
}
18+
}
19+
}
20+
}
21+
}

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.graphql.json.md

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
```json
2+
{
3+
"width": {
4+
"min": "15.90",
5+
"max": "508.00",
6+
"overallCount": 3911,
7+
"buckets": [
8+
{
9+
"threshold": "15.90",
10+
"occurrences": 1291,
11+
"requested": true
12+
},
13+
{
14+
"threshold": "97.92",
15+
"occurrences": 210,
16+
"requested": true
17+
},
18+
{
19+
"threshold": "179.94",
20+
"occurrences": 1876,
21+
"requested": true
22+
},
23+
{
24+
"threshold": "261.96",
25+
"occurrences": 531,
26+
"requested": true
27+
},
28+
{
29+
"threshold": "343.98",
30+
"occurrences": 2,
31+
"requested": true
32+
},
33+
{
34+
"threshold": "426.00",
35+
"occurrences": 1,
36+
"requested": true
37+
}
38+
]
39+
}
40+
}
41+
```

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.rest

+13
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
POST /rest/evita/Product/query
2+
3+
{
4+
"require" : {
5+
"attributeHistogram" : {
6+
"requestedBucketCount" : 20,
7+
"behavior" : "OPTIMIZED",
8+
"attributeNames" : [
9+
"width"
10+
]
11+
}
12+
}
13+
}

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram-optimized.rest.json.md

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
```json
2+
{
3+
"width": {
4+
"max": "508.00",
5+
"buckets": [
6+
{
7+
"threshold": "15.90",
8+
"occurrences": 1291,
9+
"requested": true
10+
},
11+
{
12+
"threshold": "97.92",
13+
"occurrences": 210,
14+
"requested": true
15+
},
16+
{
17+
"threshold": "179.94",
18+
"occurrences": 1876,
19+
"requested": true
20+
},
21+
{
22+
"threshold": "261.96",
23+
"occurrences": 531,
24+
"requested": true
25+
},
26+
{
27+
"threshold": "343.98",
28+
"occurrences": 2,
29+
"requested": true
30+
},
31+
{
32+
"threshold": "426.00",
33+
"occurrences": 1,
34+
"requested": true
35+
}
36+
],
37+
"min": "15.90",
38+
"overallCount": 3911
39+
}
40+
}
41+
```

‎documentation/user/en/query/requirements/examples/histogram/attribute-histogram.evitaql

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
query(
22
collection("Product"),
33
require(
4-
attributeHistogram(5, "width", "height")
4+
attributeHistogram(20, "width", "height")
55
)
66
)

0 commit comments

Comments
 (0)