release: propose 3.0.0-beta changelog (RFC) - #521

Hi @got3nks ,

Excelent work! Congratulations.

As for your questions, of course, I answer for myself, we should also hear the others:

1. I think it is more a 3.0.0. I agree with all your arguments. It is definetely a new ground to stand upon.
2. beta, for sure.
3. Not really a question :D
4. Tag line is fine for me, unless someone comes with something more creative and fun, but you certainly have a priority vote on that.

I've been thinking about that aMule release from the pace of last week work, and there is something bothering me. We still have not managed to get admin access to the organization. That limits our capabilities in some ways. I believe we are able to produce a formal release, but there are lots of configurations I cannot do, e.g. I cannot add people to the team, which clearly sucks at the moment. I also cannot create the wiki, which is too bad since we have people willing to work on that too (e.g. @frnjjq) and the aMule wiki site and forum are mostly abandoned.

So, @gonosztopi , I hope you are well, and if you are there, please give me or @Vollstrecker or @sc0w admin access so that we can go on with the work.

Regards.

Thanks @mrjimenez for the kind words — much appreciated.

Following up on this PR with a practical question.

Acknowledging up front that the upper levels of the amule-project org administration have been quiet for a while — no responses to issues, no tag operations, no release artifacts since 2.3.3 (Feb 2021).

To be explicit, I'm not advocating for a fork in any way. aMule has 22 years of history reaching back to xMule and lMule, a recognised name, an installed user base, and a contributor lineage that's worth preserving. The whole point of the work in #510–520 (and this PR closing it out) is to ship a proper release under the original project, not to splinter off.

So the practical question for the active maintainers:

Do you have enough permissions on the amule-project org to tag a release and publish the resulting draft Release once we land this PR? Specifically:

• Pushing a 3.0.0-beta (or whichever version label we settle on) tag to amule-project/amule:master.
• Either letting release.yml's auto-generated draft Release stand, or publishing / editing it on the GitHub side.

If yes — great, I'll align with whatever review cadence works for you and we can move at your pace. If org-admin involvement is required for tagging or publishing and there's a path to reach them, I'll follow whatever process you suggest.

No urgency on this PR specifically — happy to wait on the 3.0.0-beta vs 2.4.0-beta RFC discussion as long as needed.

Hi @got3nks ,

I am also not advocating a fork. I've been around for quite a while, and I know how hard it is to appear people good enough to help and add value to a project. These opportunities are rare, and should not be ignored. I see that we have one such opportunity right now, for both code and documentation.

I have just checked, and it seems that I am able to release, since the button appears to me. So from the release front, we are ok to go.

We used to have a large translator base and just before release, there used to be a general call for translators to update their work. I guess we are close to need them now, but I don't know how to call them, if they are still around.

Again I'm late to the party.

I agree with the jump to 3, as it contains foundational changes. However I not that happy with calling it beta, as mayn distros tend to ignore betas, so the testing would mostly be done by users following git. My vote would be for a plain 3.0.0 and when reports appear 3.0.1 etc.

For the translators: I can try to scratch them out of the forums and from notes in the .po-files. For the ones that can be found on github I'll open an issue where they can be tagged, otherwise I'll use the email from forums to try to contact them.

For the repo ownership: If we need to fork to get more members into the team and make use of more helpful features, I wouldn't hesitate this and give the one the rights to elevate us some time. On the other hand a new release would be the right time to so, as users don't need to adjust with the 3.0 series. I would suggest something like amule-org to stay as close to the original as possible and also add gono and scow there to enable them to participate.

For the content of this PR:

• Maybe it would be nice to have all the old contributors mentioned somewhere prominent to honour the base
• What version is set when i.e. I use zip download for the code, where no .git dir is included?

A few follow-ups now that I've had a moment to digest:

-beta suffix — agreed. Will drop it from the CHANGELOG entry as a small follow-up.

Repo ownership — refining the position from my earlier comment, I'd propose a middle path that captures both concerns:

Tag and publish 3.0.0 on the current amule-project/amule repo first. Uses the existing watcher / star audience for the release announcement — anyone who clicked Watch over the years gets an automatic notification the moment we publish, plus the long tail of forum / wiki / search-engine links keeps pointing at a live release. After a 5-year lull, that "we're alive again" signal reaches a userbase that an empty fresh org wouldn't.

Then, once the release is out, fork to amule-org (or whichever name) for ongoing development with the team properly elevated. The amule-project repo and the 3.0.0 release page can include a "the project's new home is at amule-org" pointer so anyone arriving via the announcement finds the active fork. Subsequent releases (3.0.1, 3.1.0, etc.) happen on the new org. We get the audience benefit of releasing on the existing repo without permanently locking ourselves to the old org's admin situation.

@mrjimenez has confirmed he can push tags and create Releases on amule-project, so the middle path is viable from a permissions standpoint. If that aligns with your thinking too, this is what I'd propose.

Contributors prominently mentioned — making sure I'm reading you right: do you mean in the CHANGELOG entry's Contributors section, in docs/AUTHORS.md, or somewhere else (a README banner, a separate CREDITS file)? The docs/AUTHORS.md file already preserves the full lineage — xMule (2002), lMule, aMule maintainers and developers from 2003 onward, the gold members, former developers, the whole chain. None of that was touched in this PR. My current CHANGELOG entry only credits the recent 5-year cycle though, which on reflection undersells the heritage. Easiest path I see: expand the CHANGELOG's Contributors section into a short "Heritage / Lineage" subsection that explicitly links to docs/AUTHORS.md and frames the 3.0.0 release as a continuation of the xMule → lMule → aMule chain rather than as a fresh start. Happy to draft that edit — does that match your intent, or were you thinking something more prominent (e.g. a dedicated CREDITS section in the README)?

Packaging follow-up (zip download without .git) — drafted as a separate small PR: #524 (version-check: parse .git_archival.txt as fallback when .git is absent). Standard export-subst + .git_archival.txt template; CMake reads it as a fallback when .git is absent. Verified end-to-end on macOS: git archive of master tip produces a self-identifying zip whose binaries banner-print as aMule GIT ... (Snapshot: rev. 2.3.3-NNN-gXXX) — identical to a .git-present clone of the same commit. After the next release tag lands, GitHub's "Download ZIP" button on the tag will produce binaries banner-printing as aMule <tag> ... automatically, no extra step at release time. Lands cleanly on top of current master.

Quick status: the -beta drop is up as #525 — single commit, two files (CHANGELOG entry header + lead paragraph + Known Limitations section header/lead, plus two illustrative comments in packaging.yml). Ready when you have cycles.

Since we seem to agree on the name, and it has been mentioned here, I took the liberty to create the organization before someone outside tried to do so. So amule-org is ours.

Great that you grabbed amule-org early @mrjimenez — neutralizes the squatter risk.

One coordination flag for whoever ends up tagging and releasing 3.0.0: please give me a heads-up before you push the tag. #522 wired the version-check probe to a hardcoded api.github.com/repos/amule-project/amule/releases/latest URL, so every 3.0.0 binary built today will query that repo for future releases forever. If you'd like the canonical release home to be amule-org/amule from 3.0.0 onward, we'll want to land a small URL-update commit before the 3.0.0 tag (literally one line). I'm happy to send that PR — just need to know which way you're going before the tag, since it can't be retro-fitted into 3.0.0 binaries that have already shipped.

@got3nks , it's your call. You tell me when to tag, I am not in a hurry, no pressure. We will do it properly and well.

Also, we need to give @Vollstrecker some time to warn translators, so @Vollstrecker , it is your call too.

I am not tagging before you both say it's ok.

Yes I’d wait @Vollstrecker to give us his ok too before we proceed. 👍

Oh, @got3nks , I am sorry, I see I did not answer your point.

I don't have a closed opinion on that matter (which URL should be used). Since we are going for the middle-ground solution, maybe we should leave it pointing to here, and if we start using a repo on amule-org, the next binaries would point there, but I'd like to hear @Vollstrecker and others for that.

@mrjimenez fair point that "next binaries point elsewhere" is operationally simpler — but I want to flag a wrinkle that changes the math:

Once 3.0.0 ships, every binary in users' hands has the URL hardcoded. There's no remote-config or follow-up patch we can apply. So the choice we make for 3.0.0 specifically is permanent for that cohort:

• If URL stays at amule-project: 3.0.0 binaries query amule-project/releases/latest forever. If the next release (3.0.1, 3.1.0, …) lives only on amule-org, those users see 3.0.0 as the latest indefinitely and never know to upgrade through the in-app version-check. They'd only find out via forum / package-manager / word-of-mouth — not via the in-app prompt that's specifically designed to nudge them.

• The only way to keep them informed without changing the URL is to also publish each subsequent release on amule-project in addition to amule-org. That's a dual-release maintenance burden across the entire 3.0.x line, and it muddies the "we've moved" signal for casual visitors of the old repo.

• The clean alternative is to update the URL to amule-org/amule before tagging 3.0.0. Then 3.0.0 binaries already query the new home, and future single-publish releases on amule-org automatically reach them. We can still publish 3.0.0 itself on amule-project for the existing-watcher audience — that's the middle-path I proposed earlier, and it's a separate axis from where future versions get checked from.

My position: keep the release of 3.0.0 on amule-project for visibility, but flip the version-check URL to amule-org/amule before tagging.

While I was at it I grepped for the broader picture — every amule-project reference baked into the source / docs / packaging today:

The two CHANGELOG-history hits (amule-project.de, amule-project.net from 2003) are old domain references unrelated to the GitHub org — leaving them untouched.

Out of these, the Flatpak manifest URL is the only one that affects runtime builds (it's where flatpak-builder clones source from); the AppStream bug-tracker surfaces in OS-level software-listing UIs; the rest are doc/branding-level. None affect the running binary today, but they cumulatively determine where users' "I want to file a bug / look at the project page" attention lands.

So if we're flipping the version-check URL pre-3.0.0, the natural follow-on is one batched migration PR covering all 8 of these in lockstep. I'd propose doing that work as a single atomic "migrate references to amule-org" PR, ready to land the moment the canonical URL is settled.

Curious for @Vollstrecker's take here too — version-check URL surfaces sooner than the broader sweep but the consequence per shipped binary is irreversible.

My take is clear to point to the new org before releasing anything. One clean "Turn off the lights" commit, then release, then mirgate the codebase.

Heads-up @mrjimenez @Vollstrecker — opened #526 (Draft) with the two-commit prep we discussed:

1. Flip every load-bearing URL from amule-project to amule-org (version-check API, Flatpak source, AppStream bug-tracker, README/INSTALL/docs links). Lands before tagging 3.0.0 so the released binaries don't permanently query a dead-end URL.
2. Remove all forum.amule.org / wiki.amule.org / www.amule.org / bugs.amule.org references — admins are MIA. Replaced with github.com/amule-org/amule/{discussions,issues,wiki}. Translations are URL-only swaps applied symmetrically to msgid + msgstr so no msgmerge fuzz; copyright headers and personal @amule.org emails kept as-is.

Staying in Draft until amule-org/amule is bootstrapped — the Flatpak manifest fetches sources from the new origin and Packaging CI will fail until the repo exists. Ping me when it's up and I'll flip to Ready for review.

@mrjimenez one more low-priority ask for whenever you have a moment after bootstrapping amule-org/amule: could you also create amule-org/amule-org.github.io (org-level GitHub Pages repo, just an empty repo is enough to start)? Once it exists I can send a PR to populate it with a small landing page (homepage blurb, link to the latest release, link to the wiki / discussions / issues).

This is what https://amule-org.github.io will resolve to — and #526 commit 3 already points the default Nick, About-box "Website:" line, AppStream <url type="homepage">, and Windows resource Comments at that URL because it's much shorter and reads more naturally than the bare repo path. They'll 404 until the Pages repo exists, which is one of the things that keeps #526 in Draft.

amule-org/amule-org.github.io has been created.

hi all

btw, I have the rights here too, to do new releases

about new org, to avoid the same problem in the future, I think the new org must be some owners, not only one.

maybe to avoid missundersanding is better to rename aMule to other name, like aMula for example, because there is online a lot of official webs, bugtracker, forums... without our control, what do you think?

If finally the change sucess, to avoid more contributions here, maybe we need one commit to remove everything with only one readme file which explains the migration here

about the name, maybe sound better thename-dev instead -org :)

Hi @sc0w ,

Hum, sorry, things went very fast, the org was created this morning because the name was mentioned explicitly and I was affraid someone took the name just for fun.

Btw, you have an invitation.

@got3nks , notice that you can change anything you want in the site, I just created it with a dark theme so that my monitor and eyes don't burn.

I don’t agree with changing the app name. We’re not forking — we’re continuing the work of the previous developers and maintainers. We’re only forced to use a new repo because all the admins are MIA, and we could switch back here if any of them reappear.

I’d suggest a transition period where people can still download the upcoming v3.0.0 from this repo. Eventually, yes, this repo could become just a redirect to the new repo URL.

amule-dev instead of amule-org could be nice, but we’ve already started some work under the amule-org name. That said, it’s still open for discussion based on your preferences.

I don’t agree with changing the app name. We’re not forking — we’re continuing the work of the previous developers and maintainers. We’re only forced to use a new repo because all the admins are MIA, and we could switch back here if any of them reappear.

ok, it makes sense :)

amule-dev instead of amule-org could be nice, but we’ve already started some work under the amule-org name. That said, it’s still open for discussion based on your preferences.

I said -dev instead -org, because... amule-org sounds like the web www.amule.org which we dont have write access...

We can change it, but as soon as possible if all of us are agree, there is a button to do the job, in settings of organization, at the bottom, in danger zone: "rename organization"

and in the name... aMule development :)

I agree with @sc0w amule-org could be misleading because we have no access to amule.org, but the same applies to amule.dev (which points to nothing at the moment though)

Will wait for comments from @Vollstrecker and @mrjimenez

I've put amule-org on the table because it's near to the old homepage to signalize it's still the same.

First thought about -dev: Sounds a bit like always beta.

Overall, as long as it's still amule I have no hard feelings about the naming.

Settling on a name — three reasons I'd argue for sticking with amule-org:

1. Domain ownership is a wash. We control neither amule.org (dead, admins MIA) nor amule.dev (currently nothing). So neither -org nor -dev has a real domain advantage. The "could be confused with the website" concern applies symmetrically to both — anyone landing at amule.dev from a URL bar would also be confused not to find us there.

2. amule-org signals continuity with the heritage. As @Vollstrecker put it: it's "near to the old homepage to signalize it's still the same." We're not forking — we're continuing the existing project. The org name reads as "the project formerly known as amule.org," which is exactly what we are. amule-dev would imply a clean slate, which we explicitly aren't.

3. -dev reads as WIP. Vollstrecker's "sounds a bit like always beta" is, I think, the strongest argument against. End users reading "amule-dev" in their About box, AppStream homepage URL, default nick, etc. would reasonably wonder if this is a stable project or a development branch. We're shipping 3.0.0 as a stable release; the org name shouldn't suggest otherwise.

Worth noting: PR #526 already wires ~200 files at amule-org — but that's recoverable, a sed sweep + force-push if we settle on a different name. So the existing work isn't a blocker, just a small re-do cost. The naming question should be decided on its own merits.

ok, lets keep amule-org, sorry for the noise, and long life for aMule!

3.0.0 ready for tag and release.

Where we are:

• migrate URL references to amule-org and remove dead amule.org website refs #526 merged to amule-project:master — version-check probe, Flatpak source URL, AppStream bug-tracker, README badges/links, default Nick, About-box "Website:" / "Forum:" / "FAQ:" / "Contact:" lines, and ~200 translatable strings + manpages all updated. Wiki sub-page slugs aligned with the GitHub-actual page names.
• amule-org/amule:master mirrored from amule-project:master (both at b71935541).
• amule-org/amule-org.github.io is live (replaces the placeholder).
• CI on amule-org/amule:master post-mirror: I18n CI ✓, C/C++ CI ✓, Packaging ✓ — 9/9 artifacts produced in run 25374304850 (AppImage x86_64 + aarch64, Flatpak x86_64 + aarch64, macOS Universal2 .dmg, macOS .app x86_64 + arm64, Windows portable .zip x64 + ARM64). Flatpak especially — the new origin URL (migrate URL references to amule-org and remove dead amule.org website refs #526 commit 1) is reachable and the manifest builds clean.
• Wiki: 13/13 inbound-link pages bootstrapped on amule-org/amule/wiki (Backtraces, Get-HighID, Firewall, FAQ-aMule, FAQ_eD2k‐Kademlia, Amuled, Amulecmd, AMuleWeb, Amulesig.dat-file, Onlinesig.dat-file, Translations, Translating-Wiki, Translating-Docs).

Translator outreach — non-blocker for 3.0.0

Quantified what landed: 43 new msgids total over the whole 3.0.0 cycle (1624 → 1651 in po/amule.pot, net +27 with old ones retired). For a 5-year cycle that's a small enough surface that translator coordination doesn't need to gate the tag — anything not refreshed before tag will fall back to msgid (English) at runtime, and we can land translation updates as 3.0.1 patch material on rolling basis. Sample of what's new: AppImage first-run prompt strings ("Install", "Don't ask again", "Add aMule to your application menu?"), MaxMindDB-related strings, Kad parallel-search strings, the new HTTP error path, the EC tag validation messages, the GitHub-replacement URL strings already updated in #526. Translator @-mentions / forum reachout can happen post-tag without disadvantage.

@Vollstrecker — happy to defer to your judgement here, but flagging this so it's not blocking on outreach if you'd rather move forward.

Dual-release plan for 3.0.0 (middle path we agreed on)

Per the thread consensus — and to maximize reach for the "we're alive again" announcement to the existing amule-project watcher / star audience while keeping the release also discoverable on the new home:

1. Tag 3.0.0 on both amule-project/amule:master and amule-org/amule:master (same commit, b71935541). Both repos will fire release.yml and produce identical artifacts.
2. Publish a Release on both repos — same body, same attached artifacts. People watching amule-project get notified through their existing subscriptions; people landing on amule-org see the release on its canonical home.
3. From 3.0.1 onward, releases only on amule-org/amule. The version-check probe in 3.0.0 binaries already points at amule-org/amule/releases/latest (migrate URL references to amule-org and remove dead amule.org website refs #526 commit 1), so dual-published 3.0.0 cohorts will naturally migrate to single-publish on the new home for all subsequent updates.

I'll send a small follow-up commit / PR adding a "the project's new home is at amule-org" pointer to amule-project/amule's README right after the dual-tag, so anyone arriving via the announcement on the old repo finds the active home cleanly.

@mrjimenez — happy to coordinate the actual tag + release with you (you mentioned upthread the Release button is visible to you; sc0w confirmed similar permissions). Just let me know how you'd like to proceed.

Ok, let's wait for @Vollstrecker take on translations, if the agrees, we make a step-by-step here so that I don't screw things up :D

If I understand it correctly, both repos are sync'd and we just have to tag both with the proper name, right?

Yes, exactly that — both repos are sync'd at b71935541, and tagging is the entire procedure on your side. release.yml does everything else.

Step-by-step:

1. Push tag 3.0.0 to amule-project/amule at commit b71935541.

2. Push tag 3.0.0 to amule-org/amule at commit b71935541 (same commit).

3. release.yml fires on each repo automatically — packaging matrix runs (same 9 artifacts you saw in run 25374304850 for amule-org), then a draft Release lands at <repo>/releases with all 9 assets attached and --generate-notes filled in from PR titles since the previous tag.

4. Review each draft — auto-generated notes are usually a fine starting point but you'll likely want to replace them with the curated 3.0.0 — "alive again" section from docs/CHANGELOG.md since that's the proper retrospective. Confirm the 9 assets are all present.

5. amule-project draft only — add a banner at the top of the release body marking this as the last release on amule-project/amule and linking to the new home (amule-org/amule). Suggested wording:

   Last release on amule-project/amule. Active development continues at github.com/amule-org/amule. Future releases (3.0.1, 3.1.0, …) will be published only on the new home; in-app version-check in the 3.0.0 binaries already points there, so users will be notified of updates regardless of which repo they downloaded from.

6. Click Publish on each.

Order doesn't matter; you can push both tags in succession. If anything looks off, release.yml supports workflow_dispatch with the tag name as input — re-runs the asset assembly without re-tagging.

Concrete commands (assuming you have the repos cloned with both remotes):

git tag -a 3.0.0 b71935541 -m "aMule 3.0.0 — alive again"
git push <amule-project-remote> 3.0.0
git push <amule-org-remote>     3.0.0

Plain 3.0.0 (no hyphen suffix) is detected as a full release, not a pre-release — so the Latest badge will land where we want it. If you want the same tag object on both, push the same annotated tag to both remotes; if you'd rather have two independent annotated tags with separate authorship metadata, create them separately. Either works; the artifacts and version banners come out identical because both point at the same commit.

Personally, I believe in a "non-commital" beta or alpha release before fanfare announcements, so I'm wondering why there is nothing like that on the Releases pages already. But, regardless - is there a timeline for an upcoming release?

Hello.

First and most important thanks to you all. This release is amazing, I am so impressed with the work done. The changes have been major, and many bugs could arise I think a beta is the way to go.

I agree with the movement to a new org and the "no fork" just a name change to be able to continue the project. I will contribute in the new org with presence and wiki content.