The Marten release cycle

[ar-kristina]

In my opinion there are way too much Marten releases done. Just for Marten 9 it looks like:

May, 21: 9.0.0
May, 24: 9.0.1
May, 25: 9.0.2
May, 28: 9.2.0
May, 28: 9.2.1
May, 28: 9.3.0
May, 29: 9.3.1
May, 29: 9.3.2
May, 29: 9.3.3
May, 30: 9.3.4
June, 1: 9.3.5
June, 2: 9.4.0
June, 3: 9.5.0

That's a rush, and I don't know what version is - please don't misunderstand - stable enough to use.

Why are there no pre-releases or a similar thing?
That way your Critter-stack customers could use and test the new stuff, while the actually released ones are good to use without any missing things (like all the patch releases with a single fix show).

And sorry to say, but for our companay this is a preclusion to pay for Critter-stack.
So please overthink the release cycle.

[tomap]

I see those messages from time to time (about too many updates).

For context, I work on two projects.

One has "renovate bot" enabled (works like dependabot on github)
The other does not

On the first one, I see the updates, and I usually apply them in the following 2 weeks (if the update is replaced by another update, then I take the last). I've never had an issue with an update. The biggest issue we had (and still have from time to time, but rarely), is when a API changes or is deprecated, then the update fails, and we have to update our code
On this first project, we see every udpate (renovate runs every day), and I don't see why it's an issue for you to see many update, and skip some, because you cannot follow.

On the other project, we don't have renovate bot. So in reality, we update only when there is a security issue (rarely) or when there is a new feature that we want to use

Pick one mode :)

I'm not sure why you are worried about the (too) many updates?

You would prefer one update per 6 months (that would aggregate many small commits and be published once every 6 months)
and expect this single update to be of better quality than any of the small ones?

[ar-kristina]

For instance: company policy that dictates that each update has to be validated for supply chain attacks.
I'm not worried about that in regards to Marten, but the policy doesn't make an exception therefore.

I don't prefere one update in 6 month, never said that.
But I'd prefere one update that is tested and works. For Marten 9 the issue(s) got created, then a stray of (AI) generated PRs, merged once CI passed and it got released. The next day issue were filed that this and that is missing or not working, and a new release was done.
This bothers me.

With some kind of pre-release to test, evaluate, all this troubles could be avoided.
So there could be Marten 9 release, after some pre-release testing period, which just works.
Then there can be a new release every week, every two weeks. But not a release for every bug fix, that could be avoid with a different release planning.

And Marten is such a great product (actually the whole stuff from JasperFX), so it's a shame to show up with such "incomplete" releases.
I don't want to be offensive here, but hope that this can be done better.

[jeremydmiller]

Hey man, we've discussed this a couple dozen times as a community, and I've profusely apologized over and over again for the cadence when this has happened, but very, very little of that involved regression problems except the inevitable issues right after the huge release. We've been optimizing lately for keeping the issue count as low as possible and addressing issues that do come up quickly.

As for the prerelease Nugets? We never get any useful feedback on those and IME, that's usually been a waste of time. We don't release anything that we know to be unstable.

The rapid release cycle over the past couple weeks has been the major release, which always comes w/ a few hiccups, client problems completely unrelated to the release, and a huge new feature from a client.

I'm sorry this "bothered you", but you're talking about FOSS and I don't recall you contributing in the slightest.

[tomap]

If this speeds up the validation cycle on your side, you could ask marten to be delivered with a SBOM generated. Some supply chain validation software know how to use those.