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

PackageMerging examples out of date? #112

Open
s-makin opened this issue Oct 25, 2023 · 4 comments
Open

PackageMerging examples out of date? #112

s-makin opened this issue Oct 25, 2023 · 4 comments

Comments

@s-makin
Copy link

s-makin commented Oct 25, 2023

The PackageMerging.md page uses Cosmic and Disco in the examples throughout - at one point it even says "Disco is not available yet at time of writing", which is why I first noticed this. This makes the entire page feel out of date and neglected.

I think that if it's possible, these examples should be made as generic as possible (or at least brought up to date with e.g. Jammy/Focal).

@mitchdz
Copy link

mitchdz commented Sep 13, 2024

Long live Cosmic!

@mitchdz
Copy link

mitchdz commented Sep 13, 2024

I think the package version names being out of date is fine-ish, as long as the commands and response from commands still match. Otherwise, the package will be out of date each and every cycle.

However, if we make it a goal to always keep the version names up to date that would be a good commit for first-time contributors to re-run the commands with the new versions perhaps?

@mirespace
Copy link

mirespace commented Oct 10, 2024

What about a task to update it - across all the documents? - at the beginning of a cycle?

Could we do it "automagically" with Mark Down? Setting a variable ... mmm , I think we don't automatically generate the UMH

@cpaelzer
Copy link
Collaborator

The examples refer to particular versions and git commits, so it is not a "search & replace" action.
As only in e.g. cosmic was postfix on 3.3.0-1ubuntu1 and had a fix with hash ...

So really, there is no drawback in those examples referring to "old" releases unless if they are wrong.
And they are not.
Therefore rewriting just to have newer release names is quite some effort (to get the new versions and cases) for a low gain, so I'd suggest to close this as won't fix @s-makin

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

4 participants