More frequent release schedule

[vwkd]

Helix seems to be under active development with daily commits and frequent new features - which is great.

It seems odd that the last release is often a significant fraction of a year old. For example, as of March 2023 the last release is more than three months old.

The FAQ currently says (emphasis mine)

We shoot to cut a release around every two to three months.

Has it been considered to implement a fixed and possibly more frequent release schedule? Has it been considered to fully automate the release process using CI?

A fixed release schedule takes away "release pressure", since a feature is just included if it's ready or pushed to the next release if it's not.

More frequent releases decrease effort for maintainers since bugs get reported faster.

As an example, the deno project automated their releases using a bot that creates weekly patch releases and monthly minor releases.

[askreet]

Not to say that I wouldn't appreciate nightly/weekly builds being available to users, but have you tried building from source if you're interested in the latest features? It's actually quite easy to set up the rust toolchain and install it to your system.

[pascalkuthe]

that's exactly why we need more frequent releases. Helix is in the rapid evolution phase right now.
Iterate faster, learn from users, get feedback.

VSCode took the industry by storm. One thing they did early on was to do monthly releases and patches on the need-to basis.
man_shrugging it makes sense to me to try to learn from the best and adopt practices that worked well for them.

Helixes goal is not popularity. VSCode has the backing of one of the worlds largest coopertions so they have a bit more manpower than we do. Doing an release takes significant effort (we do a one week only bug fixes and writeup a detailed rundown of the changes). Doing that regularly is not feasible for us (and the window to merge feature PRs would be pretty small if you constantly do weeks where we only accept bug fixes). @kirawi also pointed out that larger features/PRs sometimes take a while to iron out all issues on master (like the recently merged snippet support), stripping out those features again for somekind of nightly release is simply too much effort and requireing them to be 100% stable before release would bar anyone but maintainers developing larger features (and even then it would be a ton of effort to catch every contrived edgecase upfront)

master is stable enough that it should be enough for most people. Distros and people that really want a stable release simply need to be patient.

[href]

As someone who waits for releases (and enjoys the blog post that comes with it): The current pace is perfectly fine with me.

Thanks for all your hard work!

[archseer]

VSCode took the industry by storm. One thing they did early on was to do monthly releases and patches on the need-to basis.

And if we were a corporation-sized team with income to work on just helix full time, you'd get monthly releases. But we aren't. You can't compare a project like this to Microsoft.

[archseer]

Why bother accelerating the testing and regulatory checks to bring a safe drug to market, just inject the latest developmental drug we made in the lab this morning.

There’s a reason that there are release builds apart from development builds. Release builds are supposed to be stable.

Maybe you’re perfectly comfortable with using a development version and that’s fine. I believe for most users this is not a useful answer though.

You want a stable release at the cadence of a nightly build almost. That's untenable for us to manage. Having a large userbase run development builds is precisely why stable releases can even be so stable.

[debajyoti1990]

Totally unfair to compare with VScode, as there the devs got paid for their work. I believe all devs of Helix have some other full time job and after that they are doing voluntary work to fix bugs / bring new features. Releases should come when devs decide enough bugs have been fixed or enough features have been added from last release. I like many others, do not like hassle of building from master, does not matter whether it is stable or not. I want the guarantee that quarterly releases are stable enough for daily use. To be honest, I am grateful to the devs for such a great product, it is not finished yet, but already ticks many necessary boxes.

[archseer]

Disagree. Like with every other software, you should build from master if you want to live on the bleeding edge. Releases every few months are just stable snapshots, the calendar versioning is deliberate.

Releasing every few months allows us to shake out any bugs and release something stable. Users that run nightly are expected to understand how the build works and how to properly report bugs. More frequent releases make it likelier we'll ship something broken and get bad bug reports. Letting features mature before a release has been great (just look at all the snippet/completion bugs that happened over a few weeks after the merge).

A more frequent release cycle is also more labor for maintainers, we started with ~2 months per release but switched closer to 2-3 because it was hard to keep up with the timeline.

[archseer]

First of all, we adhere to ripgrep release policy.

ripgrep is a project whose contributors are volunteers. A release schedule adds undue stress to said volunteers. Therefore, releases are made on a best effort basis and no dates will ever be given.

Reality check: We've released more frequent updates than vim, neovim, kakoune or emacs. In fact, calendar versioning was specifically chosen to avoid the stigma of having to fill each release with major changes, or determining when to cut a release.

Automating the release schedule

Yes, our release builds are fully automated by CI. Sadly, writing a sensible changelog and release article takes time (and no, using a shell script to produce a wall of half-readable commit messages isn't a reasonable alternative). We also tend to have a "feature freeze" period where we avoid merging any larger PRs prior to release, so we're able to get any bugs caught.

And that is the state today. We've deliberately held back our release to wait for a tree-sitter release upstream that solves a couple significant bugs. A revert would mean that our next tagged release would still have those bugs.

The maintainers fiercely oppose certain logical and rational changes for unknown reasons.

Fierce opposition? Yes, I sometimes disagree with changes and I explain my reasoning. Sadly we can't say yes to every open issue.

infrequent release schedule

I find this absolutely ridiculous. We're already releasing at a pace where some downstreams aren't even keeping up. Rust, with tens of maintainers releases every 90 days. Until this year we were releasing every 2-3 months.

Unfortunately, the answer always is "build from source if you can't wait".

The solution is what? Daily releases? Maybe releasing after each PR is merged \s Surely that will make it even easier for downstreams to keep up.

As an example, the deno project automated their releases using a bot that creates weekly patch releases and monthly minor releases.

There is more to frequent releases than adding a CI action. If Helix had a full time engineering team and a foundation that raised a $21M series A then you'd get more frequent releases

[cd-a]

I think we all agree that the maintainers are doing an excellent job, and we are all very grateful for this excellent editor.

Let’s not have one idiotic comment spoil the mood. Someone who just complains but doesn’t do any work himself in open source projects should just be quiet.

[vwkd]

@archseer Appreciate the response.

Sadly, writing a sensible changelog and release article takes time

Writing a changelog and a release article should largely be additive, writing multiple shorter ones or one long one should largely equal in work, minus some boilerplate. I’d even argue releasing less frequently disincentivizes releases because the huge amount of accumulated changes that need to be documented.

The solution is what? Daily releases? Maybe releasing after each PR is merged \s

It seems disingenuous to suggest the only alternative to releasing a handful of times per year is once per day. This is not the original request.

If Helix had a full time engineering team and a foundation that raised a $21M series A then you'd get more frequent releases

This too seems irrational. Why would one need millions of VC money to release more frequently? Maybe the request has been misunderstood. The request isn’t for working faster - implementing more features or fixing more bugs in the same time. The request is simply releasing the current master more frequently. As we determined, this shouldn’t be much additional load on the maintainers. Blaming it on missing VC funding seems irrational.

At this point, I think the maintainers clearly demonstrate the fierce opposition to logical argument. Sadly, the project’s community meets rational arguments with accusals of harassment while simultaneously calling people “idiot”. I’m sure others could formulate the request more eloquently than me, but probably most refrain from voicing their opinion exactly because of this discouraging environment. Good luck!

[archseer]

I've written a full reply, yet you only engage a couple tangential points and dismiss them as "irrational". It's very easy to frame your statements as "logical" then dismiss disagreement as "irrational". I'd like to suggest that approaching a discussion in such a way is counter-productive and the reason responses are so negative? It's quite frustrating to take the time to sit down and write a reply not just once, but twice and have it dismissed as "irrational".

I personally don't agree with @kirawi and @cd-a's tone and am prepared to have a discussion with you, but I do find it infuriating when my statements are hand-waved away. In that case I'd rather spend the time working on the next release :)

Writing a changelog and a release article should largely be additive

It still consumes some time to compose. You've also skipped the rest of my points. In your words, it seems "irrational" to focus on just this part of the argument :)

I'm suggesting that we've already automated the largest parts of the release process, but there's still a handful of items that have to be done each time. It's a lot easier to get through the process if working on the codebase is your daily job (hence my statement about Deno being backed by a corporation, and I'll make a similar argument about vscode's release cadence and it having a dedicated team at Microsoft), but I'm not willing to guarantee I'll be able to find free time one weekend every 2-4 weeks to sit down and produce a release. Even if we add more automation, a release will never be fully automatic and you're asking me to trade my free time and put in more work to give you access to fixes sooner. Most users are happy we take 2-3 months rather than 9-12.

It seems disingenuous to suggest the only alternative to releasing a handful of times per year is once per day.

My point is, regardless of the release cadence there will always be a gap between what is available on the latest development branch and the last release. It's usually not a big deal because we release every 2-3 months, and as previously stated I'd be hard-pressed to find any other editor (besides vscode) that receives 4-6 major releases in a single year. The current process was chosen exactly so we could release 4-6 times rather than 1-2 times per year. It's only currently a problem because we missed our last release window. Kakoune attempted a monthly release cycle and also very quickly fell behind.

[cd-a]

I personally don't agree with @kirawi and @cd-a's tone and am prepared to have a discussion with you, but I do find it infuriating when my statements are hand-waved away.

@archseer I'm sorry if my tone was a bit out of line. I do welcome suggestions and discussions of opposing opinions, but the way this gentleman has been going on about just seemed very disrespectful to the work the maintainers and any contributor has been doing.

I appreciate that you are able to keep the discussion on a civil level, even though it's frustrating.

[maxchisto]

Like with every other software, you should build from master if you want to live on the bleeding edge.

If you are on Mac and want latest helix - run brew install helix --HEAD instead of brew install helix.
That's what I'm doing.
--HEAD option tells homebrew to build latest commit from master

~> hx --version
helix 22.12 (78613ac0)

[jficz]

edit: the message was apparently very badly written and it conveys a completely different meaning than intended. Please ignore it and do not engage in the discussion. Keeping the original text here just for reference

I wouldn't necessarily want to have more frequent releases (so long as the FAQ's two to three months was adhered to) but I would definitely like to see some predictability or release schedule.

Not knowing when a release will happen leads to frustration and, to be honest, quite embarrassing situations like this where a de-facto blocker bug was fixed about two weeks after a release but it took nearly 5 months(!) for the patch to be released, or this where the patch came in just a few days after a release and it is still not out (after 4 months to the date) with no ETA whatsoever.

In both cases I would like to know how long do I have to wait for a release and if it makes sense to go through the less-than-ideal ordeal of building from source (and risking more instability due to the bleeding edge nature of master).

To me an editor is one of the most important tools in the system and I need to be able to rely on it. The segfault bug quite literally prevented me from using Helix and given the release situation it was not even straightforward enough to just build from master, because of other system dependencies that were OS-specific*. So I just used Vim instead for the time being because I was not able to spend hours trying to build from source with a possible prospect of doing that every week or so (again given the unstable nature of bleeding edge).

I have two recommendations:

1. establish a more predictable release schedule so users and packagers alike have an idea of what efforts make sense and when

2. if the release schedule does not allow for fast enough releases (2-3 months is imho the threshold people would be willing to accept), consider more frequent patch releases which would only fix really bad bugs like the segfault one mentioned above

Why? I think Helix is mature enough and adopted widely enough to be a serious player. The serious league, however, plays by different rules where stability and support often come first, even if at the expense of features. An editor is a centerpiece of many people's workflows and as such the demands on stability are even more important. Helix has a great and patient community which understands that Helix is still relatively immature compared to the other serious players (Vim, Emacs, Codium, Kak ...) and people are willing to cut it some slack but as I said, Helix is getting serious and if it wants to keep being serious and grow, it needs to adopt at least some of the traits people expect form a stable product.

*) a rather unhelpful advice I got was "build with rust <1.70" which, to be fair, is not something a regular user should be expected to even understand, let alone deal with

[archseer]

From a less experienced user's perspective it is frustrating that if they want a problem to be fixed, they have to acquire a rather specialized knowledge about Rust development just to fix something that bothers them and with the added complexity of doing anti-pattern things like installing software outside package repos and then having to switch back to package release when a release comes out.

But that's how all software used to be built! There's a reason every project comes with a make install or something similar. In our case it's as simple as git clone ... & cargo build --release. We've made sure we don't depend on anything else than a rust compiler which is usually an apt-get/brew install/etc. away.

In my opinion a predictable release schedule or more frequent patch releases are something that may help with that.

We could make a release schedule more predictable by making releases huge, semver and only release every year or two when everything is tested for at least 6 months (like a lot of these other projects). Then we can do a develop branch, fork off bugfix only releases etc. It would improve stability (at the expense of more work on our end) but I'm sure the majority of our users would dislike it because time to land new features would significantly increase.

We're closer to the Linux kernel/kakoune/calver model where we move a lot faster and release a "snapshot" of the software. Actually, our stability comes from the fact that running master is so easy and popular that we've got hundreds of users running the latest commit, and when something does get broken we iron the bug out in minutes/hours. We've had PRs that were completely stable and went through rounds of fixes that would have new issues reported after the merge.

An analogy here would be rolling releases like Arch vs stable distros like Debian. By the time a Debian package releases the upstream package already received lots of testing, bug reports and fixes by Arch users!

Looks like you took my message rather personally and misunderstood it in some respects.

I was mainly just trying to clarify the direct criticisms around the particular release you mentioned. It could have been handled better and an update to be released sooner, but I'm arguing it's an exception rather than a typical experience.

e.g. #8665 (comment) also isn't "embarrassing" because it's not like that release introduced the bug, instead it was a longstanding fix. Of course there will be a gap between the fix getting merged and a release being made, but that's all software. I either wait for the release or if the fix is that important build from source in that case.

[archseer]

This real world testing is an advantage to me: the editor's commands are like mutations on a giant state machine, and while we can integration test/property test/fuzz, there's still bugs we can find from real world input sequences and files/workloads.

[willfaught]

We could make a release schedule more predictable by making releases huge, semver and only release every year or two when everything is tested for at least 6 months (like a lot of these other projects). Then we can do a develop branch, fork off bugfix only releases etc. It would improve stability (at the expense of more work on our end) but I'm sure the majority of our users would dislike it because time to land new features would significantly increase.

The gaps between the last three releases were about 5 months, which I think is his point. You're basically doing that anyway, despite not having the stability of those larger/older projects, so users are left with problems for long periods of time. Most people only use package manager builds of Helix, and those will only track official releases.

We're closer to the Linux kernel/kakoune/calver model where we move a lot faster and release a "snapshot" of the software. Actually, our stability comes from the fact that running master is so easy and popular that we've got hundreds of users running the latest commit, and when something does get broken we iron the bug out in minutes/hours. We've had PRs that were completely stable and went through rounds of fixes that would have new issues reported after the merge.

Well, no, as I pointed out above, you're moving very slowly in terms of release cadence, like "a lot of these other projects". You could iron out bugs with patch releases too. Nobody expects you to sacrifice your job or personal life to make regular releases, but you also don't have to have "a lot of these other projects"-level quality per release, either. As you said, you could just cut the latest commit periodically into a release per month or something. As the project stabilizes, those more-regular releases will get more stable too. People can pin Helix versions in their package manager if releases are too unstable. As the project stabilizes, maybe then it makes sense to have longer times between releases.

You can ship every 5 months, and if one hits a blocker, one has to use vim until the next release 5 months from now; and you can ship every month, and if one hits a blocker, one has to use vim until the next release one month from now. I know which one I and the OP would prefer.

In addition to that, the excitement of new features coming regularly will help drive momentum in the community and project.

[zetashift]

Adding my opinion to the mix, which is basically what @href said:

I also personally like the cadence. It's often enough to keep me interested, and so often that I can't keep up.

Also ripgreps release schedule reasoning still sounds valid to me, of course nobody expects maintainers/contributors to sacrifice anything, but I can very well imagine that the pressure of releasing frequently adds overhead that nobody needs.

In addition to that, the excitement of new features coming regularly will help drive momentum in the community and project.

I think a "This Month in Helix" would be more effective for this, and could even be community maintained.
Helix(and it's contributors) is very opinionated, I don't always like it, but atleast I know what to expect. I think it's okay if the maintainers collectively agree that a certain thing is better even if it is at the cost of exposure.

[pascalkuthe]

I can very well imagine that the pressure of releasing frequently adds overhead that nobody needs.

Yeah exactly we will not shorten release schedules. A release always adds pressure since you don't want a broken release so you delay PRs/prioritize fixing regresions. If you release to frequently that adds a lot of overhead.

I find these demands for a shorter release cycle always come from people not involved in the project and from a detachment our development realities.

Particularly it's a big problem for large changes (which are necessary) since if your release cycle is short you only get a very short window where the stars align that the PR is ready to be reviewed (rebased on master), actually is reviewed (and comments are adressed) so that it can be merged early enough in the release cycle to get a lot of testing (for very large changes one month in master may be barely enough). It's just not practical. Even if you don't do feature freezes/bugfix periods (because your release cadence is so shor that just means that master becomes a defacto staging branch for a release making the burden for review and merging things into master even higher (if regressions are likely to endup in the next release they become unacceptable and its a reality of development that bugs do sometimes slip trough) which would slow down development a lot.

5 months also still isn't that long compared to mature projects which have release cycles measured in years (last vim release cycle was lamoat two years, nvim is over 1 years since the last major release now, kaklune also usually does one big release per year and is currently pushing 9 months) wether one of our release cycles happens to stretch to 5 months is really immaterial to that argument.

I frankly also don't see it as that big of an issue. Got a problem that is fixed on master but not in the latest release? Build from source, it's not that hard. I find mentioning that most users use package managers (a claim that is a lot less true for helix core user base) here ironic since those often lag months or even entire release cycles behind so a faster release cadence wouldn't help there.

At the end of the day I find these demands for a shorter release cycle very entitled. You are asking us to do more work/change the way we do development. We obviously found what works well (and explained multiple times already in this thread) and have good reasons for doing things the way we are. All this change so that... you can have your problem fixed/get that shiny new feature faster. Just so you dont have to put in 10 minutes to build from source in one fo the rare cases you run into a regression.