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.

Sign up for GitHub

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

Extend the compatibility-with-leapp-repository.html #779

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Extend the compatibility-with-leapp-repository.html #779

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 17 additions & 1 deletion docs/source/compatibility-with-leapp-repository.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,10 @@ when we agree it's worthwhile.

But we need a mechanism to be able to synchronize with other projects, when we
provide new functionality in the upstream (master) branch without the need
of immadiate release of the new version of leapp. For these purposes the
of immediate release of the new version of leapp. For these purposes the
`leapp-framework` capability is provided in the framework (python[23]-leapp) rpms.


## When and how change the capability

The `leapp-framework` capability has to be changed in case of any change of
Expand Down Expand Up @@ -57,3 +58,18 @@ on the system, you could end up with:
which both are broken for leapp repository and the dependency from the point of
rpms is satisfied. This should happen rarely. We suggest you to ensure that you
use such repositories where only one of those rpms exists.


# Leapp developer's point of view
Copy link
Member

Choose a reason for hiding this comment

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

what about something like:

Suggested change
# Leapp developer's point of view
# An example story from leapp developer's POV

My point is to explain we provide an example / story to people in this section that covers the stuff above.


Some big and cool feature requests expect changes to land in both leapp and leapp-repository projects simultaneously.
To instruct how to pick up the proper version, you need to make changes to the spec files that reside in the
`packaging` directory of both projects.

For example, let's say that [packaging/leapp.spec](../../packaging/leapp.spec#L16) has `framework_version 42.42` and
the cool change you are working on is breaking previous functionality.

* In a leapp PR you would need to bump the version in the spec file to `framework_version 43.0`.

* In a leapp-repository PR you would then need to address the expected version by adjusting the Requires directive,
like `Requires: leapp-framework >= 43.0, leapp-framework < 44`
Comment on lines +65 to +75
Copy link
Member

Choose a reason for hiding this comment

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

Let's rather make it general. It does not matter whether someone is working on a functionality that needs to be addressed in both projects in the same time or whether we speak just about generic case: I want to provide new feature in leapp; I want to start to use a feature in official leapp repositories.

Suggested change
Some big and cool feature requests expect changes to land in both leapp and leapp-repository projects simultaneously.
To instruct how to pick up the proper version, you need to make changes to the spec files that reside in the
`packaging` directory of both projects.
For example, let's say that [packaging/leapp.spec](../../packaging/leapp.spec#L16) has `framework_version 42.42` and
the cool change you are working on is breaking previous functionality.
* In a leapp PR you would need to bump the version in the spec file to `framework_version 43.0`.
* In a leapp-repository PR you would then need to address the expected version by adjusting the Requires directive,
like `Requires: leapp-framework >= 43.0, leapp-framework < 44`
I want to address new feature / functionality in leapp. Let's say that looking into [packaging/leapp.spec](../../packaging/leapp.spec#L16) `framework_version` is set to `2.2` (the macro is used to set the value for the provided `leapp-framework` capability). Based on my change I need to bump the value to:
* `2.3` - if my change is providing new funcionality that is compatible with previous version, so it's not breaking anything
* `3.0` - if my change is not compatible with the original functionality, so e.g. a library function is removed, etc. whatever change that affect the current existing leapp repositories.
Now let's say the other case: I want to start to use the new leapp functionality in a leapp repository (in the leapp-repository git repo). In such a case, in the commit I start to use the new functionality (newer leapp), I check the [packaging/leapp-repository.spec](https://github.com/oamg/leapp-repository/blob/a2ae28455d4d28be62749e141a66beb35e686764/packaging/leapp-repository.spec#L99) spec file to see what `leapp-framework` is required. Let's say you see now line like this:
`
Requires: leapp-framework >= 2.2, leapp-framework < 3
`
There are possible two cases:
* If the functionality you require is provided by `leapp-framework` older than `2.2` you do not need to do anything as the required functionality is already provided in the required version of the framework (ignoring the possibility you would like to use a removed functionality provided e.g. in framework `1.1`, the lowering of the required version of the framework is just not possible in our projects).
* If the functionality you require is provided by `leapp-framework` newer/higher than `2.2` (e.g. `2.4`, or `3.0`) than update the requirement so you are sure that minimal version will be the one you require, and the highest possible version will be lower than next the next major one (where the functionality could be missing or changed). So let's say in case you need functionality in `3.5`, you are sure that you will not install framework `4.x` or newer. So for this example set:
`
Requires: leapp-framework >= 3.5, leapp-framework < 4
`

@fernflower: i cannot use triple backticks in the suggestion :/, so replace simple backticks when speking about "lines" by triple backticks instead.

Copy link
Member Author

@fernflower fernflower Jun 14, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

TBH I'd like to keep it simple and goal oriented - we already have a generic description above that doesn't really help to find an immediate answer to "How do I specify the cross-dependent versions asap" :(

I would like to keep this paragraph only for cases when leapp developer actually needs to become aware of the need to bump framework version.

Copy link
Member Author

Choose a reason for hiding this comment

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

@MichalHe @Rezney @vinzenz what do you think?

Copy link
Member

@pirat89 pirat89 Jul 26, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

@fernflower let's put it somewhere so we discuss it the next week, to have it resolved. it's not cabal topic, but possibly we could use that mtg when nobody is answering. wdyt?

or we could sync first to discover whether we find a better solution alone :)