[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

Things to consider regarding *versioning*.

The provider and user of any interface need to agree about how to interpret the
data being exchanged.  Internal-only interfaces can be changed easily, because
you can change the provider and user at the same time.  Interfaces that are
exposed externally require more attention, for obvious reasons.  To *change*
interfaces means to either remove, or add, or modify an existing interface.
Modify basically means to remove and then re-add a variant, re-using the former
name/identifier.


# [[RPC]]s

## [[microkernel/mach/message/msgh_id]]


# Shared Libraries

  * [[!wikipedia soname]]
  * ELF symbol versioning
  * [[!wikipedia "GNU Libtool"]]


## Hurd

Transition to "normal" ELF symbol versioning/libtool?

For all libraries, the SONAME is currently set to *0.3*.  [[!message-id
desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the
[[Hurd 0.5 release|news/2013-09-27]].


## glibc

Bump the glibc SONAME to some point, or can do everything with symbol
versioning?


### IRC, freenode, #hurd, 2012-12-14

[[!tag open_issue_glibc open_issue_libpthread]]

In context of [[packaging_libpthread]]/[[libpthread]].

    <pinotree> once libc is switched internally from cthreads to pthreads (thus
      breaking its BC), may be worth cleanup the hurd-specific exported symbols
    <tschwinge> pinotree: Yes.  If you already have ideas about what to clean
      up, feel free to add a new page or a section on open_issues/glibc.
    <pochu> we're gonna break backwards compatibility in glibc on hurd? that
      could be the perfect moment to fix the /dev/fd/N problem without adding
      new RPCs, though we'd probably have to break backwards-compatibility in
      the exec server IIRC...
    <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
      reminding!

[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
"4BFA500A.7030502@gmail.com"]].