#🚀 v0.12.3 - July 25th 2024

1 messages · Page 1 of 1 (latest)

lucid dove
#

Fixed a bug that has existed for a couple patch releases now: https://github.com/dagger/dagger/pull/8011

Fairly annoying to users who run into it, but probably not quite enough to call for an immediate release since there's a few other things that seem like it would be nice to get in first and we just did a patch release today.

I'm thus proposing we do another release next week (Tuesday), unless something else comes up. Let me know if anyone would prefer a different date (I'll run it either way).

cc @vagrant bay @rustic cedar @vivid plaza @near trail @shy oracle @valid glen

Milestone: https://github.com/dagger/dagger/milestone/54

vagrant bay
#

SGTM ❤️ I can also run this one, given you and @rustic cedar took the last couple

lucid dove
#

Another user hit the problem fixed by 8011: #1265311355863433256 message They are okay with waiting for next week, but just noting in case more hit it; I may bump priority on getting the fix out ASAP (like this Thursday worst case)

lucid dove
#

Eh I just saw another message from a user hitting this #1265311355863433256 message

I'm inclined to just do a release tomorrow (July 25th), I'll run it in the morning. Doesn't seem worth the pain of everyone being stuck on v0.12.0.

@Jed we can continue to plan on a subsequent patch next week to get https://github.com/dagger/dagger/pull/7858 out, but probably just hold off on merging it before tomorrow (on my TODO list to review tonight)

Let me know if there's any objections to the above

lucid dove
#

✨ v0.12.3 - July 25th 2024

lucid dove
vivid plaza
lucid dove
vivid plaza
#

Allows deprecating that undocumented feature.

lucid dove
#

🚢

lucid dove
lucid dove
lucid dove
#

Python publish succeeded but did notice this somewhat odd looking line in the output: https://github.com/dagger/dagger/actions/runs/10101086117/job/27933869141#step:3:1338

149 :     [0.1s] | Failed to parse lockfile; ignoring locked requirements: TOML parse error at line 240, column 29
149 :     [0.1s] |     |
149 :     [0.1s] | 240 |     { name = "gql", extra = ["httpx"] },
149 :     [0.1s] |     |                             ^^^^^^^^^

cc @vivid plaza not sure if that's known and harmless

#

Helm chart and all SDKs besides Go are published.

pkg.go.dev is still pending updating, seems extra long today, but everything is ready to publish once it catches up.

neat jasper
lucid dove
#

Go docs finally updated, so published that now too

#

cc @leaden osprey @unkempt summit for updating Cloud, Daggerverse and Playground

neat jasper
#

dagger-for-github. a couple to tweaks I'll make to RELEASING

#

and Daggerverse is needed too!

#

Though...I'm guessing there won't be breaking changes that fail things?
Unless a user pushes a 0.12.3 module. 😉

unkempt summit
#

Updating daggerverse rn

lucid dove
neat jasper
vivid plaza
neat jasper
#

If versions of Dagger are API-compatible, should we allow an older engine in Daggerverse to publish a newer module?

Like should we allow a v0.12.2 engine to publish a v0.12.3 module?

Gonna look at our logic around this now.

unkempt summit
lucid dove
# neat jasper If versions of Dagger are API-compatible, should we allow an older engine in Dag...

Yeah, it's tricky in the general case obviously, but 100% agree that in this particular situation that error is not accomplishing anything.
I'm not sure off the top of my head if this is the current expected behavior or if there's a bug causing this restriction. Ideally the module should be able to tell the engine it's "minimum required" version in addition to the one it was developed with most recently. Then the engine could use that to decide whether to try and load it

neat jasper
#

Have to be an exact match

#

Compare returns an integer comparing two versions according to semantic version precedence. The result will be 0 if v == w, -1 if v < w, or +1 if v > w.

An invalid semantic version string is considered less than a valid one. All invalid semantic version strings compare equal to each other.

vagrant bay
#

The way it works is that if an module version asks for a version greater than the engine currently is, it produces this error

lucid dove
#

It's a bit more than an exact match. We do allow engine-version to be newer than module-version. I think we just don't havehandle the inverse case well yet, where module-version is newer than engine-version

vagrant bay
#

We can't know in that engine version if the next version is breaking or not

#

We could relax this restriction - but we then need to not put breaking changes into patch releases

vagrant bay
#

It's just that the floor is currently 0.9.9 or something very low

#

Since we've not ever decided to purposely break any modules in daggerverse

lucid dove
#

What I was wondering is the module could know it's minimum required version based on API changes, tell that to the engine, and then that's how the engine would decide to load it or not

neat jasper
lucid dove
#

That seems like it would safely lift the restriction

vagrant bay
#

Or should we automatically detect the minimum version? That feels a bit tricky (given some changes might not actually be api changes)

vagrant bay
#

I think there is an issue where daggerverse needs to be manually updated - I wonder if we could update it before the release, or somehow we could automate the bump and merge to happen very very quickly

lucid dove
# vagrant bay Isn't that what happens? With the engineVersion parameter?

It's sending the version of the engine it was developed with most recently, which is useful. But in a case like this, v0.12.2->v0.12.3 didn't have any breaking api changes or introduce any new APIs, so it should be safe for a module that was developed with a v0.12.3 engine (and thus has that in dagger.json) to be loaded by a v0.12.2 engine. So in theory a module could say "it's safe to load me from engine v0.12.x or above"

100% agree that is extremely tricky to think through in every case and it makes sense we started conservatively here, just imagining ways it could be lifted in theory

lucid dove
vagrant bay
neat jasper
#

@unkempt summit dgvs PR approved

vagrant bay
lucid dove
#

There's still the separate case of users hitting this without daggerverse at all, i.e. I developed a module locally with a newer engine but now it's running in our own CI which hasn't updated yet.

vagrant bay
#

I guess the buildkit-style capability model helps here

lucid dove
vagrant bay
#

Yeah one day... that's the model I'd like to have once we hit 1.0

#

But also yes, it's a total pain to get your head around, you have to imagine past and future versions of clients and servers and modules all together and how they should interact

#

I'm also not 100% sure

lucid dove
neat jasper
#

A more basic issue with Go SDK that maybe we're fixing with go.mod work
Case #1

jeremytest ➤ ./bin/dagger version
dagger v0.11.2 (registry.dagger.io/engine) darwin/arm64
jeremytest ➤ cat dagger.json                                                             
{
  "name": "jeremytest",
  "sdk": "go",
  "engineVersion": "v0.12.3"
}
jeremytest ➤ ./bin/dagger call functions
# 
generating go module: jeremytest
        ┃ Error: bootstrap package: existing go.mod has unsupported version 1.22.5 (highest support
        ┃  is 1.22.2)
lucid dove
neat jasper
#

that's clearer

#

wait...I used 0.11.2? 😂

#

for 0.12.2

jeremytest ➤ ./bin/dagger version                                                       
dagger v0.12.2 (registry.dagger.io/engine) darwin/arm64
jeremytest ➤ ./bin/dagger call functions

Error: input: moduleSource.withContextDirectory.asModule resolve: failed to create module: select: module requires newer engine version: version v0.12.2 does not meet required version v0.12.3
#

there we go

lucid dove
lucid dove
#

Finished improvements to releasing process (main update is adding a few commands to replace some tedious manual version string bumps across a bunch of files): https://github.com/dagger/dagger/pull/8040

Also figured I'd try to automate at least one part of the process so we can keep taking baby steps towards "one-click release", working on automating the SDK changelog generation but decided to spin out to separate PR since it's a bit more involved

lucid dove
#

a bit more to go, hit timebox on this for today, but draft PR for that automation here: https://github.com/dagger/dagger/pull/8043

Fun fact: if you use the (non-default) --wipe option on export and your .git dir was not loaded, you can delete your .git and lose all local branches that weren't checked-out or pushed coolcrying Discovered that while working on the PR....

GitHub
[WIP] automate sdk changelog generation by sipsma · Pull Request #8...

Spinning this out from #8040
In the effort of slowly automating our release process towards being one-click (or at least "few-click"), this automates the SDK changelog generation, which i...

lucid dove
#

I just realized I never moved the milestone issues from v0.12.3 -> v0.12.4 and was about to go do it but saw someone else had. Thank you whoever did that 😄 (@Jed?)

#

🚀 v0.12.3 - July 25th 2024