On Thu, Mar 28, 2024 at 8:57 AM Jan Lukavský wrote:
> +1 to either doing full release or deferring to 2.56.0.
>
+1. Given that validation/testing required for unupdated SDKs should be
minimum, I don't think a full release will be that much overhead compared
to just releasing Python SDK. Also
+1 to either doing full release or deferring to 2.56.0.
Jan
On 3/28/24 16:52, Yi Hu via dev wrote:
> Just releasing Python can break multi-lang by default (unless
expansion service is overridden manually) since we match versions
across languages when picking the default expansion service.
> Just releasing Python can break multi-lang by default (unless expansion
service is overridden manually) since we match versions across languages
when picking the default expansion service.
Yes, that's why I proposed "the source code of release candidate (e.g.
apache_beam/version.py) still reads
On Thu, Mar 28, 2024 at 8:36 AM Chamikara Jayalath
wrote:
> Just releasing Python can break multi-lang by default (unless expansion
> service is overridden manually) since we match versions across languages
> when picking the default expansion service.
>
>
>
Just releasing Python can break multi-lang by default (unless expansion
service is overridden manually) since we match versions across languages
when picking the default expansion service.
> The patch itself [1] is trivial, however, the release process is not
trivial. There is little documentation nor practice for a patch release
process. I could imagine two options
I think there's not a ton of documentation because we haven't done it, but
all the release workflows were authored in
Thanks Valentyn for raising this. In this case, Python containers will also
be included. Different from PyPI wheels, docker tag can override so it can
stay with 2.55.0
On Thu, Mar 28, 2024 at 11:15 AM Valentyn Tymofieiev
wrote:
> If we do a patch release for Python SDK, let's also patch another
If we do a patch release for Python SDK, let's also patch another known
issue for which fix is available:
https://github.com/apache/beam/blob/master/CHANGES.md#known-issues-1
On Thu, Mar 28, 2024 at 8:01 AM Yi Hu via dev wrote:
> 2.55.0 release manager here
>
> The patch itself [1] is trivial,
2.55.0 release manager here
The patch itself [1] is trivial, however, the release process is not
trivial. There is little documentation nor practice for a patch release
process. I could imagine two options
1. Do a full "2.55.1" release
2. Do a patch release only for Python SDK, that is
a.
+1 on a patch release - we've done a fair amount of work to make releasing
easier, and one of my hopes is that it will enable quick patches like this.
I'd vote we try to fix the underlying Java piece as well, though, doing a
patch release for one language shouldn't be significantly cheaper than
+1 to a targeted patch release.
We did the same for the Go SDK a little while back. It would be good to see
what's different for a different SDK.
On Wed, Mar 27, 2024, 4:01 PM Robert Bradshaw via dev
wrote:
> Given the severity of the breakage, and the simplicity of the workaround,
> I'm in
Given the severity of the breakage, and the simplicity of the workaround,
I'm in favor of a patch release. I think we could do Python-only, which
would make the process even more lightweight.
On Wed, Mar 27, 2024 at 3:48 PM Jeff Kinard wrote:
> Hi all,
>
> Beam 2.55 was released with a bug that
Hi all,
Beam 2.55 was released with a bug that causes WriteToJson on Beam YAML to
fail when using the Java variant. This also affects any user attempting to
use the Xlang JsonWriteTransformProvider -
13 matches
Mail list logo
