I think this is a great basis for guidelines on the blog post at a minimum.
A real changelog, gathered in one place on the web page, is more useful
than scanning the blog.
The Jira version summaries are pretty close, but we would need to be much
more serious about making good titles and getting
I stumbled recently into this specification for changelogs, maybe we can
follow it, or at least use some of their sections for further blog posts
about releases.
https://keepachangelog.com/en/1.0.0/
On Mon, Aug 12, 2019 at 6:08 PM Anton Kedin wrote:
> Concrete user feedback:
>
Concrete user feedback:
https://stackoverflow.com/questions/57453473/was-the-beamrecord-type-removed-from-apache-beam/57463708#57463708
Short version: we moved BeamRecord from Beam SQL to core Beam and renamed
it to Row (still @Experimental, BTW). But we never mentioned it anywhere
where it would
On Wed, May 8, 2019 at 9:29 AM Ahmet Altay wrote:
>
>
> *From: *Kenneth Knowles
> *Date: *Wed, May 8, 2019 at 9:24 AM
> *To: *dev
>
>
>>
>> On Fri, Apr 19, 2019 at 3:09 AM Ismaël Mejía wrote:
>>
>>> It seems we mostly agree that @Experimental is important, and that API
>>> changes (removals)
*From: *Kenneth Knowles
*Date: *Wed, May 8, 2019 at 9:24 AM
*To: *dev
>
> On Fri, Apr 19, 2019 at 3:09 AM Ismaël Mejía wrote:
>
>> It seems we mostly agree that @Experimental is important, and that API
>> changes (removals) on experimental features should happen quickly but still
>> give some
On Fri, Apr 19, 2019 at 3:09 AM Ismaël Mejía wrote:
> It seems we mostly agree that @Experimental is important, and that API
> changes (removals) on experimental features should happen quickly but still
> give some time to users so the Experimental purpose is not lost.
>
> Ahmet proposal given
It seems we mostly agree that @Experimental is important, and that API
changes (removals) on experimental features should happen quickly but still
give some time to users so the Experimental purpose is not lost.
Ahmet proposal given our current release calendar is close to 2 releases.
Can we
I agree that Experimental feature is still very useful. I was trying to
argue that we diluted its value so +1 to reclaim that.
Back to the original question, in my opinion removing existing
"experimental and deprecated" features in n=1 release will confuse users.
This will likely be a surprise to
I agree 100% with Kenneth on the multiple advantages that the Experimental
feature gave us. I also can count multiple places where this has been
essential in other modules than core. I disagree on the fact that the
@Experimental annotation has lost sense, it is simply ill defined, and
probably it
if it's technically feasible, I am also in favor of requiring experimental
features to be (per-tag, Python should be updated) opt-in only. We should
probably regularly audit the set of experimental features we ship (I'd say
as part of the release, but that process is laborious enough, perhaps we
This all makes me think that we should rethink how we ship experimental
features. My experience is also that (1) users don't know if something is
experimental or don't think hard about it and (2) we don't use experimental
time period to gather feedback and make changes.
How can we change both of
I think a release version with Experimental flag makes sense.
In addition, I think many of our user start to rely on experimental
features because they are not even aware that these features are
experimental and its really hard to find the experimental features used
without giving a good look at
Our Experimental annotation has become almost useless. Many core,
widely-used parts of the API (e.g. triggers) are still all marked as
experimental. So many users use these features that we couldn't really
change them (in a backwards-incompatible) without hurting many users, so
the fact they are
> We might also want to get in the habit of reviewing if something should
no longer be experimental.
+1
Kyle Weaver | Software Engineer | kcwea...@google.com | +1650203
On Wed, Apr 3, 2019 at 3:53 PM Kenneth Knowles wrote:
> I think option 2 with n=1 minor version seems OK. So users
I think option 2 with n=1 minor version seems OK. So users get the message
for one release and it is gone the next. We should make sure the
deprecation warning says "this is an experimental feature, so it will be
removed after 1 minor version". And we need a process for doing it so it
doesn't sit
15 matches
Mail list logo
