Discussion about further naming and future of this project.

[pktiuk]

Introduction

As described in #349 there are new maintainers of this repository
It would be good to discuss what to do further in terms of development of both projects: AntiMicroX and AntiMicro

AntiMicroX was a fork of AntiMicro created in 2018, when AntiMicro already stopped development.
Later also legacy AntiMicroX was abandoned.
In that case I decided to start maintaining everything starting from the latest code.
Maybe it was not the best decision, maybe it was. I don't know. Now we are in this place we have legacy unmaintained app and the new one with a new name and branding.

What we can do now

There are two possible target approaches:
1. Focus on AntiMicroX - push code from AntiMicroX and overwrite app's name - it would be used for redirecting entire interest to the new repository with new code. Pushing these changes wouldn't happen at once, because after some time AntiMicroX stopped supporting Windows. We would just publish the latest release still supporting it and slowly continue our work at AntiMicroX with restoring its support.
Finally, we would push here AntiMicroX release restoring Windows support, leave a note about moving this project and (potentially) archive it.

Pros :

• It would be much less work for our team (currently we have only 2 devs dealing with this project in the free time).

Cons:

• It is a messy solution
• Leaving repository which already gained a lot of traction

2. Focus on AntiMicro - Backport everything to AntiMicro, use AntiMicroX as base of bug fixes and new features and apply them on top of master (apply all of them and rename everything back to AntiMicro or apply them step by step without messing with old name). Finally, we would end up with a new and shiny AntiMicro release containing all of AntiMicroX features and fixes, we could archive AntiMicroX and continue development here.

Pros:

• It would help the exact place where Windows stopped working and it would possibly help with restoring it.
• We would work on quite a popular repository.

Cons:

• It is a really problematic in terms of required workforce, because changes in codebases between two projects are colossal.
• AntiMicroX has already packages in many Linux distributions, we would have to delete/rename most of them (we already have Fedora, arch and flatpak, the only exception is Debian having AntiMicro package, but not for AntiMicroX)

3. Move entire development to AntiMicro and link it with publishing legacy releases (idea of @AriaMoradi) - we could rename current master branch master to master_legacy and force push the latest AntiMicroX master to new master here, and later rename it to AntiMicro. From this point we could continue development of our cutting-edge master branch until it will be ready to be used instead of master_legacy as a source of releases for Windows.
Pros :

• Less work than 2

Cons:

• More work than 1

What do you think about this? Let us know in the comments.

---

Update

AntiMicro will have one more (the last) release with included deprecation message, there will be also some cleanup in the issues on this repo and later it will be archived.

[pktiuk]

@AriaMoradi
Approach number 1 seems to be opposite to your question about renaming AntiMicroX back to AntiMicro, but in this case it would certainly redirect most of the traffic to AntiMicroX.

[gombosg]

As mentioned in the other issue, I vote for option 1 since our free time is a real bottleneck here.
IMO it's not the repo that is popular, the software is. The repo just gets good SEO but people can be redirected and informed easily.

[zzpxyx]

It sounds like the workforce is such a limiting factor that Option 2 won't even be feasible. Maybe I'm not understanding Option 1 correctly, but the easiest solution would be to archive the antimicro repo and only maintain the antimicrox repo.

[gombosg]

That is option 1, yes.
But archiving antimicro is only feasible if antimicrox has feature parity i.e. it's a feasible replacement for all OSes.

[AriaMoradi]

@AriaMoradi
Approach number 1 seems to be opposite to your question about renaming AntiMicroX back to AntiMicro, but in this case it would certainly redirect most of the traffic to AntiMicroX.

I think my best case scenario is still the best choice out of the 3 here.

[pktiuk]

@zzpxyx

It sounds like the workforce is such a limiting factor that Option 2 won't even be feasible. Maybe I'm not understanding Option 1 correctly, but the easiest solution would be to archive the antimicro repo and only maintain the antimicrox repo.

But before archiving it we would push some AntiMicroX releases to ensure sites like this , this and this will get "our" version.

[pktiuk]

@AriaMoradi Let me paste here your best case scenario for others (from: AntiMicroX/antimicrox#34 (comment)):

@AriaMoradi
In terms of renaming after statement of jsbackus we will have to rethink our project.
Maybe we could really go upstream and use changes from AntiMicroX in legacy AntiMicro.
We will have to think how to deal with this possibility, because It won't as simple as pushing changes on new repo, it will also require updating our packages for fedora, arch and flathub.

(since renaming the repo is related to promoting I'll write my thoughts here, if not open a new issue for it)

best case scenario

1- pull from the old project, put the current branches under legacy named ones(i.e. master -> master_legacy)
2- force push and overwrite Antimicro/antimicro with what we have got
3- maybe bump a major version?
4- distribute both versions(antimicro and antimicro-legacy)
5- remove the legacy version when we are sure antimicrox is a strict superset of the old antimicro in respect to features

less desirable scenario

1- restore windows functionality and other features if removed from legacy
2- make sure antimicrox is a strict superset of the old antimicro in respect to features
3- force push and overwrite Antimicro/antimicro with what we have got
4- package and distribute everywhere
5- maybe also distribute the old code as antimicro-legacy?

I have added your best case scenario as option number 3. (please correct me if I made a mistake in rewriting it)

[pktiuk]

We did our first step. With release 3.2.0 we have a fully functional Windows version.

Now we should decide what to do next with legacy repo.

We could for example release final release of AntiMicro with information about recommended migration to AntiMicroX and archive/abandon this repository. This would be a good attempt to migrate users to new app, but it would mean abandoning
popular repo. (@Ryochan7 @jsbackus )

We could also try to migrate newer code (pull all the changes from AntiMicroX and rename it back to AntiMicro). It would mean some mess in packaging for systems distributing antimicrox packages (Arch, Fedora, Solus... source ), but it would allow updating some long forgotten antimicro packages.
I think it would be good to ask people working with packages (@frealgagu @mirabilos @gombosg @manokara ) what do they think.
There would be also some work with migrating issues, discussions etc. to old repository.

What do you think, guys? Which solution would be better? Do you have any other ideas?

[mirabilos]

Paweł Kotiuk dixit:

I think it would be good to ask people working with packages

***@***.*** @mirabilos @gombosg @manokara ) what do they think. Debian ships an “antimicro” package, but it contains “antimicrox” binaries. I would very much prefer to not change that, as it will cause user confusion if the binaries are renamed. While the first package included “antimicro” binaries, back then, we changed it to “antimicrox” without changing the binary package name because that was not yet contained in a release and renaming packages is much harder. But now, people will have been using it, and it was released as part of Debian bullseye (*buntu in hirsute although they had the 2.23 antimicro in focal because of schedule differences for releases). If we rename the binaries etc. I’ll keep compatibility symlinks for one release (which is effort, but only once or twice). bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

[gombosg]

Hey @pktiuk !

I'm very happy about the Windows binary!

I'm also against renaming. We've been using the AntimicroX name for a while - be proud of it, keep it and don't break stuff for the growing user base. :)

If somebody wants to migrate from antimicro (mostly Windows users), they can still do it, it's easy.

(I.e. I'd just put a notice in the antimicro repo to use AntimicroX and archive it. In my opinion, no need to do more.)

[pktiuk]

@gombosg

(I.e. I'd just put a notice in the antimicro repo to use AntimicroX and archive it. In my opinion, no need to do more.)

I am not sure about this. Most of "casual" users don't use GitHub as a source of apps. Most of them use sites like sourceforge,microsoft store (what comes higher in google/bing/...)

[manokara]

Do we have control over the release at the Microsoft Store? I'm not entirely against reviving this repo, but I think most preople actively using antimicro that want to keep it up to date with the latest goodies and fixes are probably aware of antimicrox. I know some people don't really care for the latest release of software they use as long as it works for their use case. That said, the discoverability of the original antimicro is undisputed.

I asked in the Solus development channel and I think they wouldn't object to the rename if that's what's decided.

[pktiuk]

Do we have control over the release at the Microsoft Store?

No, but we know who controls it
https://github.com/mayrinck/FOSSonMicrosoftStore
@mayrinck

[pktiuk]

Hey @pktiuk !

I'm very happy about the Windows binary!

I'm also against renaming. We've been using the AntimicroX name for a while - be proud of it, keep it and don't break stuff for the growing user base. :)

If somebody wants to migrate from antimicro (mostly Windows users), they can still do it, it's easy.

(I.e. I'd just put a notice in the antimicro repo to use AntimicroX and archive it. In my opinion, no need to do more.)

@gombosg

Even if we decide to archive antimicro we should somehow redirect downloads of antimicro from sourceforge (13,761 This Week ) to antimicrox.
How to do it properly?

[pktiuk]

To properly tackle the issue of redirecting the remaining antimicro userbase, I will just release that last antimicro release with information about recommended migration to antimicrox.
I think that simply adding an additional button informing about this (similar to the one which informs about updates for Windows in AntiMicroX) and an entry in the info section. It will be enough to inform unaware people and let further usage for people willing to stay with the legacy app.

[pktiuk]

@jsbackus
Could you help me with building this last release?
I have problems witb building windows packages for it.

[pktiuk]

There will be only regular windows package in this release (I can't figure out how to build portable one :/ After changing PORTABLE_PACKAGE flag I still get regular one)

[pktiuk]

Done.
Now I will start closing old Issues (and maybe link some of them with existing ones in AntiMicroX).
https://github.com/AntiMicro/antimicro/releases/tag/2.24-final