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

Old examples use the current parent pom #3140

Open
codefromthecrypt opened this issue Mar 1, 2024 · 4 comments
Open

Old examples use the current parent pom #3140

codefromthecrypt opened this issue Mar 1, 2024 · 4 comments

Comments

@codefromthecrypt
Copy link
Contributor

Currently, the source tree holds old versions of examples. However, they use the parent-pom, which can lead to problems as we update dependencies.

I would suggest we either stop copying old versions of examples into the source tree (instead add README links to prior versions), or pin the examples to their corresponding parent poms.

For example, we could do this, but it might be better to just delete the old examples and only keep the current.

--- a/examples/examples-release-17/pom.xml
+++ b/examples/examples-release-17/pom.xml
@@ -6,8 +6,7 @@
        <parent>
                <groupId>io.kubernetes</groupId>
                <artifactId>client-java-examples-parent</artifactId>
-               <version>20.0.0-SNAPSHOT</version>
-               <relativePath>..</relativePath>
+               <version>17.0.0</version>
        </parent>
@brendandburns
Copy link
Contributor

The issue with deleting the older examples has to do with discoverability. If it is too hard to find the older examples, people file issues when the current examples don't work with older versions of the libraries.

If there is a proposal for how to achieve that (perhaps linking to git tags?) I'm open to proposals.

@codefromthecrypt
Copy link
Contributor Author

I was thinking we could add a link with the release tag in the release notes to where the example is. Since the tag won't change that will always be there. another way is we could make a release asset (tar.gz or zip) with the examples, if we think people will struggle with git checkout?

Basically, I think there are some considerations to find the right path.. ones I thought of are..

  1. are we doing this because we think users can't git checkout <release-version>? If so, we have limited options..
  • keep as-is, but unhook the parent pom so the old versions can keep coherent deps
  • attachment on a release with a zip or tar-gz they can click and get
  1. regardless, how do we communicate samples?
  • link in release notes to that version's sample
  • links in the version matrix
  • attachment on a release

what do you think?

@codefromthecrypt
Copy link
Contributor Author

(My proposal would be to keep only one sample and make sure release notes link to it by its version tag. That's the simplest, and we can edit the past releases to add this, too)

@codefromthecrypt
Copy link
Contributor Author

if we go with my suggestion, the github action has support for a default body, so I think we can make it happen automatically (text with links to where the samples are by the git tag of that release) https://github.com/ncipollo/release-action

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

No branches or pull requests

2 participants