Halide Releases should be more regular and more frequent

[steven-johnson]

As of this issue being filed, the most recent "release" of Halide was 2016/10/22 (> 3 months). Since the release versions tend to be easier for experimenters and newcomers to pull and use, it would be good to have a policy of more-frequent and more-regular releases -- strawman suggestion of once-a-month-or-so as a target would be good?

[jrk]

👍

Is there a way we can streamline the process any more? (Or is it automated enough and it just needs to be documented?)

Also, it is probably worth changing to a Semantic Versioning scheme. An increasing number of tools really want this. This should be as simple as "vYYYY.MM.DD" instead of "YYYY-MM-DD".

[abadams]

The process is to * wait until all the buildbots are green and nothing huge and possibly-breaking still needs shaking out (i.e. a poor-man's release branch) * download the right prebuilts from https://buildbot.halide-lang.org/ and upload them to github for a Halide release * write a note highlighting any major new features * If they have changed, rebuild the website tutorials using the script in the website repo * build the docs in the main repo, and copy them over into the website repo It's not a complicated process, mostly I neglect it because one of the buildbots is red most of the time. It could be automated a little more with some difficulty.

…

On Thu, Mar 9, 2017 at 2:22 PM, Jonathan Ragan-Kelley < ***@***.***> wrote: 👍 Is there a way we can streamline the process any more? (Or is it automated enough and it just needs to be documented?) Also, it is probably worth changing to a Semantic Versioning scheme. An increasing number of tools really want this. This should be as simple as "vYYYY.MM.DD" instead of "YYYY-MM-DD". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1905 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfdRtXSr8xYKb0MNVtkxu5tzWa-_YlVks5rkHulgaJpZM4MYmeX> .

[steven-johnson]

Could we add smarts to the buildbot to push notifications out to us when things are all-green... or, for that matter, not-all-green-for-some-length-of-time? Right now it needs manual monitoring.

[kgnk]

Maybe this is a good place to mention #1864

[steven-johnson]

Now that the buildbots are better/smarter/faster, probably a good idea to do a new release soon. Any particular new fixes in the pipeline that we should wait on?

[abadams]

I want to get the tutorial for Func::in done first. Working on it today.

…

On Tue, Apr 11, 2017 at 1:57 PM, Steven Johnson ***@***.***> wrote: Now that the buildbots are better/smarter/faster, probably a good idea to do a new release soon. Any particular new fixes in the pipeline that we should wait on? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1905 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfdRoIS6eBf7IkwSIIAq3mAiLDEgkBPks5ru-lBgaJpZM4MYmeX> .

[steven-johnson]

Reopening this issue, since (as of this writing) our last release was > 1 year ago. If we are going to continue to act like prebuilt releases are a Thing, we need to find a way to make them happen predictably. Among the issues I see:

• No one is actually tasked with doing them
• There aren't any criteria for how often a release should be done
• There aren't any criteria for whether 'master' is stable enough for a release

IMHO we'd be well-served by addressing each of these.

[abadams]

On point three, obviously the buildbots need to be green, but I think it would also be nice if releases corresponded to commit hashes used inside Google, to get all that extra testing surface.

[shoaibkamil]

In general, I think Google is probably a good proxy for "stable enough" except for select GPU backends that might not be used there. We could check that Adobe code has no problems when built/run with inside-Google hashes for at least some of the GPU backends. It might be helpful to have an agreed-upon checklist we can run through for every release (e.g. sanity check tutorials, push updated Python packages, etc).

For no. 2, I would advocate releases every ≤6 months.

For no. 1, it's not clear to me how much is automatable, but we definitely should find a way to not have one person be responsible for everything.

[BachiLi]

Just want to bring this up. I would love to help whatever I can do. This, plus allowing people to be able to apt-get install halide and/or pip install halide would be really nice. Some form of versioning is probably necessary.

[abadams]

We just did a release (finally). I put the instructions here: https://github.com/halide/Halide/wiki/How-to-make-a-new-binary-release-of-Halide

Figuring out how to apt-get install or pip install Halide would be very welcome.

[BachiLi]

Didn't notice the release! Thanks a lot. I'll take a look at apt-get install this weekend.

[alexreinking]

Still not on APT or PIP, but we are on Homebrew and vcpkg. Probably safe to close this 🙂