Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
This repository was archived by the owner on Sep 9, 2025. It is now read-only.

Comments

Close side panel

Add document detailing release strategy for libraries#125

Merged
nathan-weinberg merged 1 commit intoinstructlab:maininstructlab/dev-docs:mainfrom
nathan-weinberg:lib-release-stratnathan-weinberg/dev-docs:lib-release-stratCopy head branch name to clipboard
Oct 18, 2024
Merged

Add document detailing release strategy for libraries#125
nathan-weinberg merged 1 commit intoinstructlab:maininstructlab/dev-docs:mainfrom
nathan-weinberg:lib-release-stratnathan-weinberg/dev-docs:lib-release-stratCopy head branch name to clipboard

Conversation

@nathan-weinberg
Copy link
Member

Resolves #124

@nathan-weinberg nathan-weinberg marked this pull request as ready for review August 1, 2024 18:27
Copy link
Contributor

@dhellmann dhellmann left a comment

Choose a reason for hiding this comment

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

We spent a lot of time describing release "models" for related projects in the OpenStack community. The document describing those models might be interesting reading for folks thinking about the same topic for InstructLab.

A few things to consider that aren't mentioned here:

  1. It's harder than it seems to make the version numbers of the CLI and libraries line up exactly and makes things more confusing to users and rebuilders. I recommend not even trying.
  2. Versioning schemes like SemVer can help signal when a new release has breaking changes, but it's still better to make releases backwards compatible as much as possible to ensure adoption of new releases.
  3. It makes it easier to reason about release series if the release branch is created from a tagged commit. That can be a .0 release or a release candidate release.
  4. For libraries, no one can easily consume release candidates because they aren't installed automatically, so over-using them will make things harder, not easier.

docs/library-release-strategy.md Outdated Show resolved Hide resolved
Copy link

@markstur markstur left a comment

Choose a reason for hiding this comment

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

see comments

docs/library-release-strategy.md Outdated Show resolved Hide resolved
docs/library-release-strategy.md Outdated Show resolved Hide resolved
docs/library-release-strategy.md Outdated Show resolved Hide resolved
Copy link
Member

@RobotSail RobotSail left a comment

Choose a reason for hiding this comment

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

This is all very reasonable and will help out with broader communication across different groups. LGTM.

@nathan-weinberg nathan-weinberg force-pushed the lib-release-strat branch 2 times, most recently from 4a6710f to 4b6e2ba Compare October 18, 2024 14:49
Signed-off-by: Nathan Weinberg <nweinber@redhat.com>
@nathan-weinberg
Copy link
Member Author

I am going to merge this given the two approvals and amount of time it has sat in the queue, if anyone wants to iterate on these policies feel free to open up a followup PR for discussion

@nathan-weinberg nathan-weinberg merged commit 018313f into instructlab:main Oct 18, 2024
@nathan-weinberg nathan-weinberg deleted the lib-release-strat branch October 18, 2024 14:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Draft document detailing release procedures for new libraries

6 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.