Most kakoune packages provided by distros are based on the release version, as this has the strongest guarantee on stability and is more suitable to something in an official repository.
I know a lot of people here build the latest git version, or even uses a custom-hacked version of kakoune. But installing kakoune through a package manager certainly has many desirable benefits, too, and is the recommended way for new-comers and casual users.
The current latest release of kakoune is v2020.01.16, which is already half year behind.
During the last half year, kakoune has evolved and become (even) better, and I think it would be desirable to bring these changes to (more) people through a new release. Besides, publishing a release is also a good way for the community to reflect the works done and plan for the future. So I wonder if the next release of kakoune is on the schedule? And if it is, what would be its highlights?
I feel like we are reaching a point where we might need a (gasp) release strategy. As the project matures and gets more users, changes slowly will trickle in – I remember when it built in debug mode by default.
The project is fairly fast moving still (which is a great thing), so I think the best strategy might be a quarterly release cycle. I am talking entirely out of my ass here, I got no buy in from @mawww or anyone else, just waxing poetic at this point.
I like the time oriented release strategy because it has a few good features, first of all – it doesn’t put pressure on the developers to try to wind up to, or down from working on features. It lets a group of people break off and start testing what we hope will be a stable release for like 30 days and that group can fix critical bugs (backport fixes).
Lets pretend we started this cycle July 1st.
…
July: dev dev zug zug
Aug: cut branch at end that will become Q3 release
Sep: testing the RC for Q3 release, backport fixes, etc.
Oct 1st: release Kakoune 2020.Q3 release
Oct: dev dev zug zug
Nov: cut branc at end that will become Q4 release
Dec: testing the RC for Q4 release, backport fixes, etc
Jan 1st: release Kakoune 2020.Q4
… repeat.
This is part of the release strategy of the OCaml community (which is large and have many enterprise users), which I personally consider fairly reasonable.
· When a planned release is, say, a month ahead, the project does not accept new features any more, but only bug fixes.
· Some developers, usually those very familiar with the whole project, starts working on the release, doing testing, bug fixing, etc., aiming at solving known issues and improving stability.
· During this period, other developers can still commit new features, but their commits would be temporarily hung up, until the release is published.
Considering the fact that release version is the version for most people to use for months, its stability should be the main concern. When a serious bug occurs in a published release, something awkward like a time-traveling PR back to a release in the past becomes unavoidable. One vote for a timed release cycle, BTW.
I’m inclined to say that it’d be better to just cut a release every couple of months rather that doing all the feature freezing mess. I’ve never once had stability issues running from git, myself.
Well, the mpv way is indeed easy. But as aforementioned, in case bugs occur after the release, solving it in the released version becomes way harder. I think the mpv way relies heavily, or even essentially, on the fact that they release in a swift one-month cycle. Their way is just unacceptable for a longer cycle, in my opinion. Not that the mpv way is bad. I think a similar swift cycle without much effort on the release itself is suitable for kakoune, too.
It depends on how the community view the release. If we consider release versions just snapshots for distros, I’ll vote for the mpv way. But if we take releases more seriously, I’ll say the mpv way is undesirable.
I dont think I’ll do feature freeze for releases for a simple reason: I want working on Kakoune to remain fun, which means if I feel like working a a feature rather than fixing a bug, I dont want not to do it because we are in feature freeze time.
The current policy is basically to release every few months and wait a bit before releasing if a risky change has been added. I do agree that policy is failing and a release is overdue. Maybe a way to fix that is indeed to say that there should be a release every other month and have a bot on the IRC channel nagging me when its been more than 2 months since last release.
When a release has a big bug, the idea is just to do another release with the fix as soon as possible.
@mawww I am not convinced that it needs to be you who does it. For outside packagers to pick it up it would have to be blessed by you. But I could easily imagine a world where you work merrily on and someone else takes the reins of generating a RC, and prepping it for release.
There are a few people I imagine could handle such a role with relative ease, with a little official support (a way to update the webpage, I would post it here and on reddit, etc). I think if the scheduling is by and large mechanical, and there is always another one just 90 days away – the ebb and flow of the project could remain mostly unchanged. We might have a dud release every once in awhile, but we have a high number of daily active users – hopefully we would squash most critical ones in the RC process.
EDIT: Additionally, if a bad one goes out, it will likely only be used for 60 days because hopefully they will pick up the next RC as it drops. Also, kakoune isn’t too challenging a build even for neophytes, so hopefully in a pinch that is the fallback.
Generating a release is a pretty easy process already, the reason I dont release more often is just that there is not enough pressure to release, I suspect a nagging bot would be enough (It's been 60 days since last release, time for new one once day). If a bad one is out re-releasing with a fix is easy as well.
I am not really keen on a purely mechanical schedule because features are not always independant, for example I’d be tempted to remove dynregex highlighters in next release as it seems we can replace it with hooks and regular regex highlighters relatively easy now that we have the RegisterModified hook. Pushing those changes in the same release is a clear signal that scripts must be updated. I still want to do breaking changes from time to time, and it seems like it would be less disruptive to have the ability to group them together, which is something easier to do with a manual release cycle where we can delay.
I agree it adds risk to delay further and further, the C++ standard migration to the train release model (every 3 years) was done due to that issue that made C++11 appear 13 years after the previous major release (C++98, C++03 being mostly a bug fix release).
Easy for our side, less easy for packagers depending on how quick they are… and how quick we are… which is also why my example used 3 months instead of a lower number, I don’t want to exhaust anyone kind enough to package up kakoune for distros.
I believe the train system is better for even these cases. It gives an obvious, 4 times a year point for bringing in such big breaking changes, right after the RC is cut. This is a point script authors can prepare for, rather than having it occur randomly. It maximizes the time for testing such changes by all tiers (1) source users for 3 months, (2) rc users for 1 month. In my experience, if I can’t make a merge window, I end up being grateful for the extra time because it wasn’t baked yet, and shouldn’t be rushed. Kakoune is critical software for a lot of us at this point.
I will stop trying to sell you on the train, unless I am making progress convincing you, then let me know and I will throw in my next batch of reasons! That said, the bot reminding you getting us 6 releases a year might not be as ideal to my mind as a hard schedule, but I will take what I can get.
You are actually making progress, I am sure that bot could get stricter over time, even starting to warn about upcoming release at some point, then eventually doing the release automatically unless told overwise…
While installing kakoune today, I noticed the version in the official Arch Linux repository is 9 months out of date. This seems to correspond with the latest version on github. Might it be time for a new release?
