Inquiry about release cadence and dependency updates

[CSC-swesters]

Hi team!

Are there any plans to tag a release soon?
I'm mostly concerned about security and dependency updates, not asking for any specific feature to be released.
To be more specific, the #2884 NodeJS dependency updates still seem to be unreleased in the top-level ondemand package.

I verified that the newest ondemand-nodejs-3.1.3-1.el8 didn't show up in a fresh Rockylinux 8 installation via the OSC ondmenad latest el8Server web repository. Instead I get:

[root@box /]# rpm -q ondemand
ondemand-3.1.0-0.1.start.1.el8.x86_64
[root@box /]# rpm -q --requires ondemand | grep "ondemand-"
ondemand-apache = 3.1.0-1.el8
ondemand-gems-3.1.0-0.1.start.1
ondemand-nginx = 1.20.2-1.p6.0.14.ood3.1.0.el8
ondemand-nodejs = 3.1.0-1.el8
ondemand-passenger = 6.0.14-1.ood3.1.0.el8
ondemand-ruby = 3.1.0-1.el8
ondemand-runtime = 3.1.0-1.el8

I know you have the nightly repository on yum.osc.edu, but I'd rather have your expertise involved with tagging a proper release from the master branch, since you know much better than I do what the state of the master branch is 🙂

On a more general level, do you have a release cadence that you aim for, so that sites can roughly know when to expect releases? If I can make wishes, it would be appreciated if there was at least a maintenance release every 2-3 months, but as often a possible is of course good too!

Thanks a lot for your hard work!

[johrstrom]

Are there any plans to tag a release soon?

Yes, I'd like to get 3.1 done in the next 2-3 months.

On a more general level, do you have a release cadence that you aim for

Not really - we just try to publish about as fast as we can manage.

it would be appreciated if there was at least a maintenance release every 2-3 month

I'm trying to push 3.0.2 in the next 2 weeks or so. But this won't have any dependency updates.

[CSC-swesters]

I'm trying to push 3.0.2 in the next 2 weeks or so. But this won't have any dependency updates.

I see. I assume you won't consider backporting the #2884 fixes to the release-3.0 branch, based on your response? In that case, we'll need to consider picking a suitable point in the nightly repository and using that until 3.1 gets released.

Not really - we just try to publish about as fast as we can manage.

Totally understandable. Release management is a complex challenge.
Is the rationale for postponing the 3.1 release that you'd like to have a certain feature done, or something else?

From an admin point of view, I'd be interested in maintenance updates getting delivered independently of feature development, but of course that takes time and effort to arrange. Let me know if you have any thoughts on this.

[johrstrom]

Is the rationale for postponing the 3.1 release that you'd like to have a certain feature done, or something else?

Yea the big feature that needs a little work is the path_selector. I would have liked more progress on the new job composer - but that'll just have to keep.

From an admin point of view, I'd be interested in maintenance updates getting delivered independently of feature development, but of course that takes time and effort to arrange. Let me know if you have any thoughts on this.

Not sure what you mean. I am working on 3.1.0 and 3.0.2 mostly concurrently. Though, as you indicate I'm not ready to backport #2884 to 3.0 just yet. I mean we can, and have before, it's just messy.

[CSC-swesters]

Not sure what you mean. I am working on 3.1.0 and 3.0.2 mostly concurrently.

My motivation is to keep our OOD instances secure and up to date. From a production deployment standpoint, I'd like to have the dependency updates, which usually include security updates, tagged in releases and available via the OSC latest Yum repository. Whether that would be in the release_3.0 branch or some other branch does not matter per se. In production we'd like to be running an officially released version of OOD.

This whole issue could be classified as a wishlist item, for two reasons, the way I see it:

1. I would like to avoid building OOD from source, if I can. Because I'm lazy 🙃
2. I would like you, as the upstream, to indicate with git tags, or Github releases, at what point you find the code to be stable enough for someone to use it. In an ideal world, this would be any point in the master branch, but that's of course not guaranteed. So some guidance of what you deem "good enough to ship" would also be appreciated.

From what I gather in this conversation, it seems like our best bet at the current time would be to try out a nightly build. We do have the infrastructure to try these out before going to production with them, it just requires a bit of testing. Also, deciding when to pick our next deployment candidate from the nightly repositories requires that we follow the master branch more closely. This decision could be aided if we had git tags, or something else to indicate when a stable-ish version is available.

Let me know if I'm not making sense, and I'll try to rephrase 🙂

I mean we can, and have before, it's just messy.

Of course, that's understandable.

I'm mostly trying to understand your motivations with the release roadmaps as an upstream, and see how it affect our needs. As an end result, I hope to know what to expect from you in terms of security update releases, so that we know whether we'll need to look into nightly releases or not when we find an issue we want to mitigate.

I appreciate the discussion!

[johrstrom]

1. I would like to avoid building OOD from source, if I can. Because I'm lazy 🙃

I think the way we build packages (RPMs) is pretty solid because we use containers. So yes, you're building it from source code - but you're not deploying it from source and it was built in an immutable environment (the container). So theoretically an RPM you build on your machine would be the same as the one we host given you built it from the same git checkpoint.

I would like you, as the upstream, to indicate with git tags, or Github releases, at what point you find the code to be stable enough for someone to use it. In an ideal world, this would be any point in the master branch, but that's of course not guaranteed. So some guidance of what you deem "good enough to ship" would also be appreciated.

Release branches (i.e., release_N.M) should be fairly stable. Indeed, master may also be relatively stable as well WRT backward comparability - i.e., features that we've already shipped. It would contain new features that may be half backed/unable to turn off/would change in future releases.

Also - git tags correspond directly to the RPM that's built. So for example 3.0.1 RPM was built from the 3.0.1 tag. I'm fairly sure that the rake tasks that build rpms figure out if it's on a branch or if it's a tag or what.

[CSC-swesters]

Thanks for the help!

I feel like this issue isn't going to progress any further, but at least I'm more clear on what to expect in terms of releases. I'm happy to close this issue now.

Looking forward to 3.1.0 whenever you're ready 🙂