Any plan to release next version?

[Gigitsu]

Hi all,

is there any plan for a new version release of ranger? I see that from the v1.9.3 it's been a while and there are some bug fixes (like the trash bug fix), so I was wondering if it could be a good time to release a new version.

[toonn]

Yes, when it's done. Unfortunately I cannot make any promises with regards to a schedule. Due to how long it's been since the last release and how long it's likely to be after the next one I'd like to get at least all the serious known bugs fixed.

A great way to help is looking at the milestone for 1.9.4 and testing whether PRs fix what they say they do without breaking other things. Priority is any PRs that fix issues with the bug label (usually such PRs are tagged with the bug label as well), then PRs that fix other issues, then other PRs. Looking through issues in the milestone and finding small reproducing cases or confirming whether they're still an issue are helpful too.

I'm going to leave this issue open for now because it seems like people need a place to ask this question but the issue tracker should be kept to tracking bugs in the software as much as possible.

Thank you for your patience!

[Gigitsu]

Hi @toonn, thanks.

I'll definitely have a look at the milestone and try to help release the next version as best as I can.

I agree with you that the issue tracker is not for asking questions but I didn't know other way to ask, sorry for that.

[mavaa]

I just came looking for this as well just now, so thank you for the answer, and love the application.

FYI, maybe you know, it's possible to pin issues so they show up at the top of the issue list: https://docs.github.com/en/issues/tracking-your-work-with-issues/pinning-an-issue-to-your-repository

Maybe an idea to pin (and maybe rename) this issue, if a lot of people come asking for this?

[amano-kenji]

I think you should change how you do release. It's been 3 years without a new release.

Looking at issues in 1.9.4 milestone, it may take 30 years to see 1.9.4.

Taking decades to maybe see a patch release is not a good way to manage releases.

You should delete 1.9.4 milestone and release regularly as long as there is no crippling bug.

My release system publishes patch releases for bug fixes, minor releases for enhancements, and major releases for breaking changes.

Remember perl 5? Because it took decades to release perl 6 as raku, most people moved away from perl 5 toward python and other languages. People are moving toward lf and other file managers because ranger is not seeing new releases, not because other file managers are better.

Also, you should merge pull requests faster. https://github.com/jtdaugherty/brick/pulls shows it's possible to merge or close all pull requests. If you don't have time to maintain it yourself, you should add maintainers.

I'm using lf despite its lack of features and the fact that it exposes users to ANSI escape codes because it releases more often and is maintained better.

[eMPee584]

Yeah it's been 550 commits since v1.9.3 – that's more patches than the distance to prior version 1.9.2 .. The current development ambition doesn't seem to match resources available. It's great to strive for perfection, but it is the enemy of good.. I would also be in favor of dropping milestones and recommend switching to a purely time-based release rhythm.

[toonn]

For those who want time-based releases, there are packages like ranger-git on the AUR and Ranger can also be installed or even run from a clone of the master branch quite easily. The release process is too manual to do on a regular schedule with the manpower we have.

Thinking of 1.9.4 as a "patch release" is not accurate. Ranger does not adhere to semantic versioning. I wish I could do a better job of releasing bug fixes but there just isn't time, I'm sorry. Contrary to the name, the milestones are not set in stone, I often kick issues over to the next milestone. The only things I really want resolved are known and deemed important bugs. So testing PRs in the 1.9.4 milestone that are labeled with the "bug" label would be super helpful.

I wish I could merge PRs faster but I'm just not 1337 enough to review them fast enough. I know it's annoying for contributors and I know it leads to people giving up on trying to get their changes merged, which in turn gives me more work because I need to pick up where they left off to get things in shape. Believe it or not I'm doing my darnedest.

If only it was as easy as snapping my fingers to get more maintainers. I am constantly on the lookout for people who are willing to shoulder some of the maintenance burden but so far no one's had the patience and endurance to show us they're both willing and capable of dealing with the boring stuff.

I've recently found some time and I've been catching up on the backlog, here's to hoping I won't run out of steam until I get through. Determined Karate Kid stare into the horizon.

[amano-kenji]

For a project of this scale, I would consider delegating maintenance and coding to other people and focusing purely on managing maintainers. I mean managing other people's time and energy.

[mavaa]

@amano-kenji If you would take a look at the activity since jan 2022 here: https://github.com/ranger/ranger/graphs/contributors?from=2021-12-30&to=2023-03-11&type=c

I see 101 commits from toonn, and a total of 12 commits from "other people." I get that you have some ideas about how this project should work in an ideal world, but the harsh reality is that many of these open source projects live and die solely by the work of a single person (or a few people)

[amano-kenji]

I get that you have some ideas about how this project should work in an ideal world, but the harsh reality is that many of these open source projects live and die solely by the work of a single person (or a few people)

In many cases, the project creators refuse to add maintainers because they want tight control over which commits are merged. They want control, but unfortunately they don't have enough time to do it themselves.

Fear of losing control prevents project creators from adding maintainers.

Maybe, they need to write rules for merging pull requests so that maintenance can be outsourced to other people.

Or, if you are busy with a job, then you should maintain only one project.

I usually merge pull requests which don't introduce breaking changes minutes after I discover them. I don't want to drag them into the future. Quick judgements and outsourcing can increase speed.

[toonn]

I constantly keep an eye out for potential maintainers. I just expect some regular contributions first and I do want to have an impression that people care about code quality and facilitating other contributors rather than being focused on adding some features they want personally.

[iambumblehead]

https://github.com/ranger/ranger/pull/2466

This sixel PR was first submitted Oct 9, 2021 exactly one and a half years ago. A review was requested there a few days ago, but there has been no reply.

Politely, it would be great if maintainer(s) would consider the following,

• Use Ranger's project settings to invite recent contributors as project collaborators (for example Remi at the linked PR). Allow new collaborators to merge, close and facilitate PRs and issues, if they choose.
• For stalled but mostly-working PRs (for example the Sixel previewr at the linked PR), accept some of those PRs into the master branch and, afterward, apply any nit-pick or finishing changes using follow-up PRs

[toonn]

I've been waiting for all the review comments to be addressed.

[donovanglover]

For those looking for something new, joshuto is a ranger-like alternative written in Rust.

I used ranger for over 5 years and am thankful for everyone that worked on it, however joshuto has everything that I liked about ranger and loads directories much faster.

[iambumblehead]

I don't want to be a person that pushes the discussion way off-topic but...

It would be awesome if the ranger repo itself would keep a listing of all ranger clones for every language. For each listing; the language used, a link to the upstream repo, two screenshots small-terminal and big-terminal. A chart listing various capabilities, for example, is the ranger clone able to preview webp images? does the ranger clone run in windows? How big is the download size or dependency tree? etc

To bring the discussion back on topic, I use ranger on a guix system and guix only provide the "latest release" which is still 1.9.3 I could setup my own package, or clone the ranger project etc but it would be just great if the latest ranger version had all of the latest features.

[amano-kenji]

For those looking for something new, joshuto is a ranger-like alternative written in Rust.

I just searched. There is also XPLR. I'm getting tired of file managers. I don't know which one is going to serve me for a long time.

I'd like to become tool-agnostic.

[iambumblehead]

xplr looks very polished with font icons and help menu https://github.com/sayanarijit/xplr

https://www.reddit.com/r/linux/comments/shuhbt/xplr_a_hackable_minimal_fast_tui_file_explorer/

[amano-kenji]

xplr's extensibility and flexibility can be a disadvantage because it can easily make the program complex.

Joshuto is simpler. I tend to lean toward simpler programs after being tired of programmable tools.

Can xplr be simple?

[donovanglover]

I didn't know about xplr. Although interesting, I think existing ranger users will prefer joshuto since it's a drop-in replacement. Joshuto also has icon support and the help menu is accessible with ?.

[iambumblehead]

Please excuse me for being rude by sharing something so off-topic but... want to share this innovative new one with @amano-kenji and @donovanglover its called "broot" https://dystroy.org/broot/ https://github.com/Canop/broot

It does have file and image previews. Start broot and start typing a search word and in real-time it interactively lists recursive results found in the working dir. To run a command, hit space first then start typing a word like "move" and there's a little descriptive area with commands for moving files etc. It kind of reminds me of the way google search works.

The ui sort of adapts to whatever you are doing so it looks differently depending on what's going on but here's a screenshot

[eMPee584]

Ok well @toonn how about calling current git tip the 1st release candidate for 1.9.4? 😀

[toonn]

@iambumblehead, we have a wiki page for exactly that purpose. Doesn't include broot and xplr nor Joshuto yet though. Feel free to add those!

@eMPee584, believe it or not, I'm still intending a new release. It's just very hard to get those last couple bugs fixed. What little time I have to spend on Ranger usually goes into responding to issues and PRs because it feels bad to leave contributors hanging. There's also a bit of a "everyone who cares is running the master branch by now anyway," feeling, making a new release feel less urgent.

I am still dedicated to maintaining Ranger and looking for candidate maintainers with the patience to let us gain confidence the project would be left in good hands.

[eMPee584]

Well what are them "last couple bugs"? The 159 open issues in the v1.9.4 milestone :sweat_smile: :sweat_drops: ?

Why not either tag monthly releases or create a 1.9.4 beta release (with a list of known issues), so ordinary people and distro packagers can more easily get a fresh version and provide testing feedback?

[toonn]

Everything in the milestone labeled bug. We already try to keep the master branch stable so labeling anything as beta or monthly doesn't add anything.

[squid-slime]

i think one positive change could be to give the ranger git the title of nightly or something that denotes it as being ahead of the standard either way keep up the good work toonn!

[toonn]

@squid-slime, that's up to package maintainers. We don't enforce that name.

[iferc]

believe it or not, I'm still intending a new release. It's just very hard to get those last couple bugs fixed.

I understand how things can get busy and I appreciate tools like these being open and available. I'm also not sure I understand the idea behind holding off until some arbitrary checklist of bugs is fixed. Are they bugs that don't exist on 1.9.3 and therefore 1.9.4 would be introducing lots of bugs?

The reason I ask is because I had a brief moment of thinking I was going crazy when I found my issue having been resolved in 2020. I thought surely installing via apt shouldn't be 4 years out of date, but that turned out to be the case. I should have looked at the releases page sooner 😅

Smaller atomic releases might be a better strategy as it would also prevent GitHub issues like these. Anyway, still appreciate all the efforts of you and all the maintainers here. I'll switch to using master for now, and I suspect I'll never think to come back and update since most things I have tend to come from package managers.

[sudocurse]

There are 56 bugs open for 1.9.4. The oldest of these is 9 years old. I'm happy to help debug or prioritize, but i would highly encourage setting a pre-release candidate milestone. I would very much like to see an updated version of this pinned in nixpkgs.

[iambumblehead]

@donovanglover what do you think of https://github.com/sxyazi/yazi?

[donovanglover]

I recently switched from joshuto to yazi and haven't had any complaints. It's simple to configure and gets the job done

[eMPee584]

Ok let's try to break the gridlock 😅💦 First sorry to the team, I had proclaimed the intent to help with PR review, then got stuck in a lot of other tasks and the usual bit of procrastination..

Realistically, resolving the 62 open issues/PRs in the v1.9..4 milestone will take several years at least. Many of these are rather special use cases, while several common bug fixes are among the 720 commits since v1.9.3 4 years ago.

An easy option would be to tag the current master v1.9.4 and rename the milestones to v1.9.5 and v1.9.6 respectively. The manual changelog could be dropped as many other projects have done in favor of git logs. Although the editorial work is appreciated that summarized 523 commits v1.9.2..v1.9.3 in 51 changelog entries 🤩

Our Open Toolchain Foundation could probably provide some funding, would that help the core team? or to pay someone external, f.e. via upwork.com to review the patch queue and work on bugs.. at least until the FLOSS AI programming agents are more usable.. 😏 or maybe https://github.com/plandex-ai/plandex/ can deal with this project already, worth a try 🤔

This most advanced file manager ever is one of the most important tools in the computing eco system, we should really look for solutions to kick up development somehow. The alternatives that were brought up as of yet pale in comparison to ranger's power and potential..