Release cadence?

[dead10ck]

Hello, thank you for all your hard work on this project! I couldn't find anything that documented this, but I couldn't help but notice that the last release was September 2020, almost a year ago. Yet, there has clearly been a lot of development in that time.

Is there any method to when new releases are cut for the project, so that downstream OS's like Fedora, Ubuntu, etc, can release updates through official channels? Are there any feature roadmaps or periodic schedules that are used to guide new releases?

[sidkshatriya]

Yes, a lot of current distributions are carrying the 2020 Sep release which is quite old by now in terms of development. One of the first things I do when I start a new VM is fire up a kakoune gcc build! My guess is that people who are big fans of kakoune would always be compiling from tip even if releases were more frequent. So the real target audience is people who are new to kakoune or people who need to do ad-hoc editing without requiring some of the newer features of kakoune. Do they need a more frequent release? That is a question this project needs to figure out.

I have an alternate suggestion. I think the project should move away from a date based version e.g. 2020.09.01 etc. I feel that it instantly "dates" the project. If one encounters an old "date version" of a piece of software that person might (wrongly) conclude that the project is stagnant etc. In kakoune's case, development is still active. Going to a less meaningful 1.1, 1.2 etc. I think is better.

A good example is the neovim project. The project was on 0.4 .x for a long time. Only recently has it turned 0.5. Yet people probably didn't think too much about it because there was no date in the version string.

Recently a major piece of functionality that removed ncurses was merged in. I'm wondering if the project will wait a bit before the edge cases are identified before creating a new release (I don't know -- I'm just speaking as someone who is passionate about kakoune -- I'm not part of any decision making structure). Here it maybe a good idea to create a "retrospective release" -- everything upto (but not including) the "terminal-ui" feature and name it 1.0 so the next release can come when its ready.

[dead10ck]

So the real target audience is people who are new to kakoune or people who need to do ad-hoc editing without requiring some of the newer features of kakoune. Do they need a more frequent release? That is a question this project needs to figure out.

I've gotten that impression from this project that there is a prevailing attitude among kakoune enthusiasts that "serious" users should just build it themselves from the source. I find this quite puzzling. How many "serious" n/vim users compile it themselves? Very few I would suspect.

Neovim has been on 0.4.x for a while, but that doesn't really mean much. It has gotten point releases at least every few months, complete with release notes for those who care to look. I realize kakoune is primarily targeting developers, but this does not mean that all the benefits of standard package management go out the window. If most developers had to compile all their tools themselves, they wouldn't get anything done; kakoune should be no exception.

For those who wonder how active a project is, the versioning scheme doesn't make it much harder to find out. Semver would be a great idea, but certainly not to obfuscate how infrequently the project cuts new releases. These are separate problems.

[sidkshatriya]

(With the usual caveat that I speak only for myself and I'm not part of any decision making structure of this project)

I agree that it is a good thing to have more releases. In an ideal world we would have that. My impression of kakoune is that its run as a pure open source "passion" project -- there are no deadlines, no desire to acquire hordes of users (it's great if they join but the primary urge is to be a great editor and not necessarily the most popular one) and things are released when they are ready -- however long that takes. Release notes, regular releases etc. do bring in a bit of chore element to whoever needs to do it.

Kakoune does not have a huge number of dependencies like Neovim does. Neovim is easy to build because of the great documentation and release engineering but relies on a sizable number of external dependencies. Kakoune OTOH is trivially simple to build. You may already know this but kakounes now does not have any external library dependencies! You just need to run make install. That's it. That is your apt command, your dnf command, ... I hope you get the point. Building in the case of kakoune is trivial.

For those who wonder how active a project is, the versioning scheme doesn't make it much harder to find out. Semver would be a great idea, but certainly not to obfuscate how infrequently the project cuts new releases. These are separate problems.

The point of moving away from a version number that has a date into it to a numerical point release one is not to obfuscate things. The point is to avoid miscommunicating "staleness". Kakoune 2020.09.01 is a perfectly usable version for normal editing, still. Of course when you want to start adding plugins and so on it helps to run master. FWIW I build neovim locally from source every few days. It just does not make sense to wait for the long periods between releases.

Anyways you have raised some valid points -- Lets wait for @mawww and others to give some authoritative responses...

[dead10ck]

The point is to avoid miscommunicating "staleness".

That's kind of the point I'm trying to make though. It's not really a miscommunication at all. If you're not building from source, the project is stale, for all practical intents and purposes. If you're not pushing releases, users who don't build themselves never see the updates. All the work of the past year may as well not have happened if it's never released.

There are also valid reasons to prefer not working on the bleeding edge. Some users prefer a level of stability, which is also sometimes what proper releases communicate. It says the developers tested a particular point in the code to a point that they felt it was good enough to release to many thousands of people. Enthusiasts who want the latest changes may not mind if they encounter a bug, and would happily report it to the developers, but there are also many that would prefer an editor that "just works."

Which isn't to say that kakoune isn't well tested or that it doesn't "just work", but the perception of stability is a lot different when it's through an official package manager vs right on the tip of the development branch.

Whether this perception is warranted for this particular project is another debate, but this perception exists nonetheless.

I can empathize with the extra work it takes to keep up with release cadences, packaging, branching strategies, etc, and that "making kakoune super popular" may not be something at the top of the developers minds. But it does have benefits. The more people use it and like it and depend on it, the more resources it will get, in volunteer developers, donations, etc.

[Screwtapello]

As I recall, the original intention was for Kakoune releases to be monthly, for all the reasons you propose. In practice, mawww had kids, and 2020 happened, and things slipped.

That said, on 2021-08-04, mawww said on IRC:

So, after running for several days collecting normal mode commands, I seem to use p twice as much as I use P, and o dominates clearly O as well. This is good news as it means there is no strong reason to swap those commands and break the world. I think I will swap ! and <a-!> for consistency (making ! append after selection and <a-!> before) and I now need to experiment a bit with selecting inserted text on p/P !/<a-!> to see if I like it

In any case, I intend to make the long overdue next release soon

[dead10ck]

@Screwtapello ahhh, that makes a lot of sense. I had kids myself, so I totally understand how that makes free time much shorter. Thanks for the background info 🙂

[Screwtapello]

People watching this issue probably already know, but for closure: since this issue was created, Kakoune v2021.08.28 was released.

[sidkshatriya]

We have also had Kakoune 2021.10.28 and Kakoune 2021.11.07. Things are much better on this front this year!

[ismay]

I was wondering if it’s maybe time for another release? It would be great to not have to compile kakoune manually to get an up to date version.