ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801

Closed
kszucs wants to merge 3 commits into
apache:masterfrom
kszucs:so-versioning
Closed

ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom
kszucs:so-versioning

Conversation

@kszucs

@kszucskszucs commented Jul 4, 2019•
edited
Loading

Copy link
Copy Markdown
Member

Described by @kou on the mailing list:

If we may break ABI compatibility each minor version up
release ("Y" is increased in "X.Y.Z"), we should include
minor version into SO major version (100, 101 and 102 in the
following examples):

  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0

If we don't break ABI compatibility each minor version up
release, we just use the same SO major version (100 in the
following examples) in 1.0.0:

  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0

I choose 1XX as SO major version because we already use
10-14 for SO major version. We should not use them in the
future to avoid confusion. So I choose 1XX in the above
examples.

We can change this schema later, but to resolve the CI failures we need a solution for now.

@kszucskszucs changed the title [C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs requested a review from pitrouJuly 4, 2019 11:57
xhochy
xhochy approved these changes Jul 4, 2019
View reviewed changes

@xhochyxhochy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.

@xhochyxhochy mentioned this pull request Jul 4, 2019
Closed
pitrou
pitrou reviewed Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt Outdated
pitrou
pitrou approved these changes Jul 4, 2019
View reviewed changes

@pitroupitrou left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)

@pitrou

pitrou commented Jul 4, 2019

Copy link
Copy Markdown
Member

@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034

@kszucs

kszucs commented Jul 4, 2019

Copy link
Copy Markdown
MemberAuthor

Ahh, thanks for notifying me.

@pitrou

pitrou commented Jul 4, 2019

Copy link
Copy Markdown
Member

Can you cancel the old builds on your Travis and AppVeyor account?

@kszucs

kszucs commented Jul 4, 2019

Copy link
Copy Markdown
MemberAuthor

Done.

@pitroupitrou closed this in 380d0a7Jul 4, 2019
@pitrou

pitrou commented Jul 4, 2019

Copy link
Copy Markdown
Member

I merged to unstuck other PRs. Thank you!

kszucs added a commit that referenced this pull request Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport mentioned this pull request Aug 1, 2019
Closed
@koukou mentioned this pull request May 16, 2024
Closed
This was referenced May 17, 2024
Merged
Open
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
ARROW-5848: [C++] SO versioning schema after release 1.0.0 - #4801
Closed
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Closed
ARROW-5848: [C++] SO versioning schema after release 1.0.0#4801
kszucs wants to merge 3 commits into
apache:masterfrom 
kszucs:so-versioning
Conversation
@kszucs
@kszucskszucs
commented
Jul 4, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Described by @kou on the mailing list:
If we may break ABI compatibility each minor version up

release ("Y" is increased in "X.Y.Z"), we should include

minor version into SO major version (100, 101 and 102 in the

following examples):
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.101.0.0
  • 1.2.0 -> libarrow.102.0.0
If we don't break ABI compatibility each minor version up

release, we just use the same SO major version (100 in the

following examples) in 1.0.0:
  • 1.0.0 -> libarrow.100.0.0
  • 1.1.0 -> libarrow.100.1.0
  • 1.2.0 -> libarrow.100.2.0
I choose 1XX as SO major version because we already use

10-14 for SO major version. We should not use them in the

future to avoid confusion. So I choose 1XX in the above

examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
@kszucskszucs
changed the title
[C++] Update SO versioning for release 1.0.0ARROW-5848: [C++] SO versioning schema after release 1.0.0Jul 4, 2019
@kszucs
kszucs
requested a review
from pitrouJuly 4, 2019 11:57
xhochy
xhochy
approved these changes
Jul 4, 2019
View reviewed changes
@xhochyxhochy
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, quite happy with this. I don't expect us to have a longterm stable ABI yet. Once we have reached this, we should slow down on SO version bumps.
@xhochyxhochy
mentioned this pull request
Jul 4, 2019
 Closed

pitrou
pitrou
reviewed
Jul 4, 2019
View reviewed changes
Comment threadcpp/CMakeLists.txt
Outdated

pitrou
pitrou
approved these changes
Jul 4, 2019
View reviewed changes
@pitroupitrou
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, please merge quickly :-)
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
@kszucs Need to re-run cmake-format, see https://travis-ci.org/kszucs/arrow/jobs/554237034
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Ahh, thanks for notifying me.
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
Can you cancel the old builds on your Travis and AppVeyor account?
@kszucs
kszucs
commented
Jul 4, 2019

Copy link


Copy Markdown

MemberAuthor
Done.
@pitroupitrou
closed this
in
380d0a7Jul 4, 2019
@pitrou
pitrou
commented
Jul 4, 2019

Copy link


Copy Markdown

Member
I merged to unstuck other PRs. Thank you!
kszucs added a commit
that referenced
this pull request
Jul 22, 2019
@kszucs
ARROW-5848: [C++] SO versioning schema after release 1.0.0
a11bdbc
Described by @kou on the mailing list:
> If we may break ABI compatibility each minor version up
> release ("Y" is increased in "X.Y.Z"), we should include
> minor version into SO major version (100, 101 and 102 in the
> following examples):
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.101.0.0
> * 1.2.0 -> libarrow.102.0.0
>
> If we don't break ABI compatibility each minor version up
> release, we just use the same SO major version (100 in the
> following examples) in 1.0.0:
>
> * 1.0.0 -> libarrow.100.0.0
> * 1.1.0 -> libarrow.100.1.0
> * 1.2.0 -> libarrow.100.2.0
>
> I choose 1XX as SO major version because we already use
> 10-14 for SO major version. We should not use them in the
> future to avoid confusion. So I choose 1XX in the above
> examples.
We can change this schema later, but to resolve the CI failures we need a solution for now.
Author: Krisztián Szűcs <szucs.krisztian@gmail.com>
Closes#4801 from kszucs/so-versioning and squashes the following commits:
81519fe <Krisztián Szűcs> cmake-format
74a8cbf <Krisztián Szűcs> fix full so-version in comment
431ef56 <Krisztián Szűcs> update SO versioning
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

@koukou
mentioned this pull request
May 16, 2024

Closed


This was referenced May 17, 2024
 Merged


Open

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@xhochyxhochyxhochy approved these changes
@pitroupitroupitrou approved these changes

Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

3 participants

@kszucs@pitrou@xhochy