Skip to content

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.

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 <[email protected]>

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