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

Versionning scheme and publication automation #230

Open
ymorin-orange opened this issue Nov 29, 2024 · 2 comments
Open

Versionning scheme and publication automation #230

ymorin-orange opened this issue Nov 29, 2024 · 2 comments
Assignees
Labels
documentation Improvements or additions to documentation Java Python Python code question Further information is requested Rust Rust code Schema JSON schema files
Milestone

Comments

@ymorin-orange
Copy link
Member

What:

  • We currently have no versionning scheme for the release of the various components.
  • Components are not automatically published to the corresponding "registries" (crates.io, PyPi, Mavenc central)

Expected:

  1. There is a clear policy about the versionning scheme. Shall we have:
    • a single versionning for all components and release everything at once?
    • a versionning per language, and release all components in that language at once?
    • a versionning for the SDK as a whole and release a single SDK in all languages at once? If so, what about the various components (e.g. in python)?
    • a versionning per component in each language?
  2. Once the versionning policy has been established, how do we enforce it:
    • github workflows to publish?
    • how to detect that comething has to be relased:
      • tag fomatting scheme?
      • metadata in tag commit log?
    • where to publish the JSON schemas?
@ymorin-orange ymorin-orange added documentation Improvements or additions to documentation Java Python Python code question Further information is requested Rust Rust code Schema JSON schema files labels Nov 29, 2024
@ymorin-orange ymorin-orange added this to the Sprint 5 milestone Nov 29, 2024
@nbuffon nbuffon moved this to Open in its-client Dec 3, 2024
@nbuffon
Copy link
Member

nbuffon commented Dec 5, 2024

  1. We all agree that one version for all is not suitable
  2. No version change in functional branches
  3. Version changes have to be made in dedicated branches
  4. When merging into master, check the diff to identify if any version has changed.
    If any, build and publish the new package at the new version; and a new git tag is created language.module-version
  5. If at publish a package at this version already exists, the pipeline job must fail
  6. Example are not published
  7. Semantic tags (created manually): YYYYmmdd.HHMM-purpose
    E.g. 20241120.1212-Demo-5GLab
  8. Version should follow the X.Y.Z form where X is major, Y minor, and Z fix (see https://semver.org/)
  9. Create a new webpage (gh-pages)
  10. Rust packages are published on crates.io; and documentation on docs.rs
  11. Python packages are published on pypy.org; and documentation on readthedocs.com
  12. Java packages are published on ?

@nbuffon nbuffon modified the milestones: Sprint 5, Sprint 6 Dec 13, 2024
@nbuffon nbuffon moved this from Open to Ready in its-client Dec 13, 2024
@nbuffon
Copy link
Member

nbuffon commented Dec 13, 2024

  • Document the release process (previous comment content) in a file at the repository root (e.g. RELEASE-PROCESS.md)
  • Create dedicated issues by language

@nbuffon nbuffon modified the milestones: Sprint 6, Sprint 7 Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation Java Python Python code question Further information is requested Rust Rust code Schema JSON schema files
Projects
Status: Ready
Development

No branches or pull requests

5 participants