#New Critter Stack Release Policy?

1 messages · Page 1 of 1 (latest)

keen remnant
#

Hey all, there was some feedback last week about the appearance that Marten is "just an experimental playground and not usable for production" because of the number of releases that we do -- and I'll take most of the blame there. As an example, I did purposely push 7.30 out last week to get a new feature into the hands of a client, then less than an hour later they & I identified a problem w/ Weasel from another recent feature for their shop and yes, Marten got a 7.30.1 on the exact same day.

As a proposal actually from the guy who irritated me in the first place, how about:

  • New, biggish features in Marten go into an alpha release. Especially if it's for a JasperFx client and only go into "releases" later?
  • I get that it gives an appearance of us being slapdash and out of control, but I'd still prefer to just do bug fix releases and keep the open bug count as low as possible rather than letting things build up
  • To some degree I think it's a moot point for a bit because after the next Marten 7.31 late this week I'm planning to pretty well stop all further feature work on Marten 7 to focus on Critter Watch, Marten 8, and Wolverine 4.

At the same time though, the original discussion was obnoxious and outright rude. I blocked two different people on GitHub last week after not having done that in quite a long time. Life is short, and I personally can't handle too much negative incoming. I kind of hate to do this, but assuming I work on having a thicker skin too, how do you feel about us having some kind of code of conduct across this server and all Critter Stack related things? I'd probably just wanna go find one from another project and copy it.

#

As far as Marten not being production worthy because of the sheer number of bug fix releases we have to do, I think my response is something like:

  • Marten is especially vulnerable to permutation bugs that are almost impossible to account for ahead of time, with LINQ being a particularly pernicious source of problems due to the bazillion different ways it gets used in real life
  • The strong typed identifier support has been problematic, again just because of the permutations. We've made four different releases involving improvements to the custom value type stuff
#
  • We try to address bugs quickly in most cases, even though some do admittedly languish if they're just too expensive to address quickly
#
  • Marten is probably a little too big and complicated for a 3-4 person core team to be supporting all the time. I'm hoping to have more of full time company behind it in the years to come.
#

Meh, this all got cut off some how.

#

I wanted some feedback on changing critter stack releases a bit to:

#
  • Using alpha releases for big new features, especially if they're meant for a specific JasperFx client. That's more overhead on my part I don't particularly care for, but I'll buy into that
  • I'm not enthusiastic about moving to some kind of regularly scheduled release cadence because that's just not how anything really works in an OSS project
  • I get that it looks bad when we (I) make several bug fix releases in quick secession. I guess we could batch more up. My personal preference is to try to keep the open issue count as low as possible most of the time.
#

And also:

#
  • Just flat out slow down the cadence of new releases I guess. Marten 7 especially has been a pretty crazy flurry of activity this year. Quite a bit of that was from the community at large
#

And lastly, we can talk about how I certainly need to have a thicker skin, but I'm not down for getting too many obnoxious interactions online from people upset and unnecessarily negative. I think I'd like to go steal some other project's code of conduct and start pasting that in somewhere. I've maybe blocked 3-4 people ever on GitHub, but twice in the past week.

surreal lion
#

I can understand that the current release policy might seem "slapdash and out of control" from the outside,
but from the inside, as a user I really appreciate how quickly bugs are fixed, PRs are reviewed and merged, and new nuget packages are pushed!

It gives me the opportunity to jump into the code myself, figure out whats going on, send a PR, and I will get unblocked in a couple of days!

A code of conduct seems like a good idea! Even tho I don't think rude people really care about it.

About the proposed alpha-versions and slower release cadence - sounds reasonable!

keen remnant
#

"A code of conduct seems like a good idea! Even tho I don't think rude people really care about it." -- honestly, that's just setting me up to block people who are just being obnoxious without adding enough value to offset that

meager trail
#

I'm disciplined enough not to upgrade to a x.x.0 version ever unless its a couple weeks old and anyone who hasn't learned that yet is either going to learn that on your project or somewhere else 🙂 - upgrading the day of a release is choosing to be a beta tester and even Microsoft reminds us of that all the time.

#

I think eventually you can consider breaking up your major versions by LTS so people don't feel "compelled" to upgrade major versions to get security/bug fixes. EF Core does this. Granted they have some dedicated contributors where-as you do not so isn't an

image.png
buoyant drift
# keen remnant Hey all, there was some feedback last week about the appearance that Marten is "...

Wow, I can't believe that there are some people complaining that bugs are fixed and features are added too quickly. Personally, i am against the alpha-releases idea because it creates unnecessary friction in the release process and creates a backlog for fixes / features not released yet. And it's not even clear which problem this is supposed to address.

I've seen so many projects with fixes not released for weeks or months that to me the release cadence of the Critter Stack is a testimony of its quality : not every project can afford to release so frequently. For let's not forget that Marten has the most robust test suite and testing policy for PRs that I've personally seen for this kind of project, so it's not like the release cadence is hurting quality or something similar.

I know a storage project that I will not name with basically no test suite and regressions leading to data corruption every fifth release. But even there, no one is complaining that they release too frequently. We just cope by being very cautious with the cadence at which we upgrade, for the benefits of frequent releases outweigh the cons, and the only real fix would be to create a proper test suite anyway.

I concur that as a user and occasional contributor, the fact that stuff are merged and released often with the Critter Stack is a big part of what motivates me to contribute and dig into the source code.

I think that you have actually found a great balance with the way you push certain changes to major release and include others in minor ones. And major releases do have alpha versions. i'd also note that no one forces people to upgrade to the latest version without testing... Every project has a different versioning policy, I think it is on people to familiarize themselves with the release schedule of the Critter Stack and its meaning instead of asking you to fix things that aren't broken

#

One last thing is that there is something engaging with the fact of being part of a community being so active: i continually read release notes, take a look at the source code regularly, read discussions and issues etc... the release cadence contributes to the dynamism of this community in my opinion. If the new message is ignore everything if it's an alpha or beta, the engagement of the community will likely diminish.

As far as i am concerned, the Critter Stack is what has made me participate in open-source. The quality of the code, but also the dynamism of the community, including the frequencies of the releases. I find myself spending more time on Github and contributing more to projects since I started hanging in this place, the dynamism here is contagious.

keen remnant
#

@buoyant drift Thank you for writing up all of that! Made my day.

meager trail
#

I'll second that my message was an indication of I support the fast releases 🙂 People should recognize that "timing" on when to opt-in to releases matters in upgrade cycles.

I am in my Friday afternoon looking at my upgrade to Wolverine 3.0 and Marten 7.2 -> 7.3 plus. Happy to report "it just worked" . I spent the most time simply deliberating with myself if I would refactor to fix my dependencies to work without Lamar and decided I wanted to go with the more proven and feature complete DI framework and added Lamar back to my project 😁

keen remnant
#

And thank you for the support folks, I do appreciate it.

#

And also, as night follows day, there is always a brand new, completely unrelated bug report coming in mere moments after doing an ambitious bug fix release.