Release Schedules

[dcowden]

There is broad community discontent about the current state of releases, which do not have any predictable schedule or pattern.

I think everyone would agree that anything predictable would be an improvement, but I also know there is broad community disagreement about what will work best.

Here are a few proposals that have been made:

Pre-scheduled. This provides some predictability, but is not popular with (volunteer) maintainers because we can't commit to any particular schedule

ARE ( Automated regular interval). The proposal here is to auto-build at some interval, whether there's something new or not. This assuages concerns from people feeling pressured to meet deadlines, but produces a lot of useless releases. A typical implementation is a nightly build. This also doesnt address a key scheduling component, which is when 'non-nightly' builds would happen

** On demand** Here, a new release is cut when there's something worth building. This is good for volunteers-- when you're read, ship it! but its unpredictable for users

Are there other strategies we should consider?

[Jojain]

Automated regular interval doesn't not have to be nightly build. I assume you can make them montly or enve 3-month interval so there is low probability of having useless build ?

Having regular non automated builds is some extra work core dev probably don't want so I do see it really an option.

[jmwright]

I do agree that we need to release more often.

Having regular non automated builds is some extra work core dev probably don't want so I do see it really an option.

As the maintainer who normally does the releases, I agree with this. There is more that goes into releases than what many people realize (especially when OCP and OCCT are updated), and we have never documented it anywhere. It's also easy for things to become broken when we're updating OCP and OCCT, and an automated system might publish needlessly broken releases periodically. It's hard enough for the core devs to keep things from breaking in this situation. We should probably document the release process during the next release cycle so that the load/knowledge of doing releases can be spread among the core devs and so that we can know which automation options to explore to make future releases easier to do.

[dcowden]

Thanks. I agree that we should document the release process. Lets see if we can get someone else to do the release, that way we'll know the docs are complete. that can be me if we have to. The OCP/OCCT situation could change in the near future, so it might be good table more talks till after that

[jdegenstein]

I find on-demand releases to be fine personally. That being said, the current stable release of CQ is about 23 months old, and does not even have Sketch yet! The community is really in need of new releases of both CQ and CQ-editor. Currently I have to point python newcomers in discord to my static builds of CQ-editor for the easiest user experience, which is really not ideal for anyone.

[jmwright]

Since we're about to start January, we could start doing releases every 6 months (January/June). We could do every quarter instead (3 months), but I'm not sure we need/want to yet.

My suggestion would be to move to a January/June release schedule and re-evaluate for quarterly later, if needed. There is this project for the 2.2 release, but it shows that it hasn't been updated since July.

So, the release in January 2023 would be 2.2, June 2023 would be 2.3, and so on.

It's arbitrary, but at least it will give projects that depend on us more frequent releases to pin to.

[dcowden]

That sounds good to me. I think we should release at a schedule comfortable with those people who are doing the work. I've not been one of those people so I don't want to vote.

…

On Sat, Dec 31, 2022, 12:37 AM Jeremy Wright ***@***.***> wrote: Since we're about to start January, we could start doing releases every 6 months (January/June). We could do every quarter instead (3 months), but I'm not sure we need/want to yet. My suggestion would be to move to a January/June release schedule and re-evaluate for quarterly later, if needed. There is this project <https://github.com/CadQuery/cadquery/projects/7> for the 2.2 release, but it shows that it hasn't been updated since July. So, the release in January 2023 would be 2.2, June 2023 would be 2.3, and so on. It's arbitrary, but at least it will give projects that depend on us more frequent releases to pin to. — Reply to this email directly, view it on GitHub <#1115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ44A34N3UICBX2MJI2R2TWP7BDBANCNFSM52J7EJ5A> . You are receiving this because you authored the thread.Message ID: ***@***.***>