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.

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

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

Closed
wants to merge 3 commits into from

Conversation

kszucs
Copy link
Member

@kszucs kszucs commented Jul 4, 2019

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.

@kszucs kszucs changed the title [C++] Update SO versioning for release 1.0.0 ARROW-5848: [C++] SO versioning schema after release 1.0.0 Jul 4, 2019
@kszucs kszucs requested a review from pitrou July 4, 2019 11:57
Copy link
Member

@xhochy xhochy left a comment

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.

cpp/CMakeLists.txt Outdated Show resolved Hide resolved
Copy link
Member

@pitrou pitrou left a comment

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
Copy link
Member

pitrou commented Jul 4, 2019

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

@kszucs
Copy link
Member Author

kszucs commented Jul 4, 2019

Ahh, thanks for notifying me.

@pitrou
Copy link
Member

pitrou commented Jul 4, 2019

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

@kszucs
Copy link
Member Author

kszucs commented Jul 4, 2019

Done.

@pitrou pitrou closed this in 380d0a7 Jul 4, 2019
@pitrou
Copy link
Member

pitrou commented Jul 4, 2019

I merged to unstuck other PRs. Thank you!

kszucs added a commit that referenced this pull request Jul 22, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants