are orthogonal
>> IMO. The former, as Dmitri mentioned, accumulates important changes in
>> categories (highlights, breaking changes, new features, fixes). The
>> latter is a "list of everything".
>>
>> The change-log is populated manually in a PR. It
release-notes (as a list of all commits) are orthogonal
> IMO. The former, as Dmitri mentioned, accumulates important changes in
> categories (highlights, breaking changes, new features, fixes). The
> latter is a "list of everything".
>
> The change-log is populated manually
+1 on having a CHANGELOG. That's been proven to be very useful.
Change-log and release-notes (as a list of all commits) are orthogonal
IMO. The former, as Dmitri mentioned, accumulates important changes in
categories (highlights, breaking changes, new features, fixes). The
latter is a
gt; >
> > > > It's a good idea.
> > > >
> > > > I think each committer should be responsible to update the CHANGELOG
> > > > if appropriate, and reviewer should point it out if needed.
> > > >
> > > > It's the
ould be responsible to update the CHANGELOG
> > > if appropriate, and reviewer should point it out if needed.
> > >
> > > It's the same as documentation, license update and header (when code
> > > is copied from another project), etc.
> > >
> > &
header (when code
> > is copied from another project), etc.
> >
> > Regards
> > JB
> >
> > On Thu, May 15, 2025 at 9:10 PM Dmitri Bourlatchkov
> > wrote:
> > >
> > > Hi All,
> > >
> > > As discussed in the community
There is some manual overhead, but I think the alternative is worse
(breaking changes go untracked). It's a good idea to have an ongoing
changelog like this, and I don't see a way to manage it other than manually.
Your point around consistency is an important one. The example in the
lin
ntation, license update and header (when code
> is copied from another project), etc.
>
> Regards
> JB
>
> On Thu, May 15, 2025 at 9:10 PM Dmitri Bourlatchkov
> wrote:
> >
> > Hi All,
> >
> > As discussed in the community sync today, Pola
hu, May 15, 2025 at 9:10 PM Dmitri Bourlatchkov wrote:
>
> Hi All,
>
> As discussed in the community sync today, Polaris evolves quickly and
> breaking changes are a reality we have to live with :)
>
> However, I'd like to propose improving user and developer experience by
&
May 15, 2025 at 12:10 PM Dmitri Bourlatchkov
> wrote:
>
> > Hi All,
> >
> > As discussed in the community sync today, Polaris evolves quickly and
> > breaking changes are a reality we have to live with :)
> >
> > However, I'd like to propose improving use
normalize
> entries at cut time, or should each PR author follow a template up front?
>
>
> Yufei
>
>
> On Thu, May 15, 2025 at 12:10 PM Dmitri Bourlatchkov
> wrote:
>
> > Hi All,
> >
> > As discussed in the community sync today, Polaris evol
? Should the release manager normalize
entries at cut time, or should each PR author follow a template up front?
Yufei
On Thu, May 15, 2025 at 12:10 PM Dmitri Bourlatchkov
wrote:
> Hi All,
>
> As discussed in the community sync today, Polaris evolves quickly and
> breaking changes a
Hi All,
As discussed in the community sync today, Polaris evolves quickly and
breaking changes are a reality we have to live with :)
However, I'd like to propose improving user and developer experience by
keeping a change log with a section for breaking changes.
We follow this practi
I agree that breaking changes are inevitable on the main branch, but to
Russell's point there are people with deployments of Polaris in production
and I think it's unfair to them to simply say "there can be no breaking
changes" because there hasn't been a GA rele
Onofré
wrote:
> Hi
>
> I think we are mixing breaking changes and stable branch.
>
> Keeping the main branch stable is super important, I totally agree.
> However it’s ok to introduction breaking changes in main compared to other
> branches.
> By breaking change I mean
Hi
I think we are mixing breaking changes and stable branch.
Keeping the main branch stable is super important, I totally agree.
However it’s ok to introduction breaking changes in main compared to other
branches.
By breaking change I mean something that don’t behave the same or has been
removed
bert,
> >
> > That's fair and I agree: the story will be different when Polaris
> > 1.0.0 will be out. From an end-user, it makes perfect sense.
> >
> > As the 0.9.x branch exists, from an integrator standpoint (people
> > building something on top of the
get it merged, and then someone else decides that same field should be
an int and attempts to merge that. The +1's on the second PR are
essentially post review -1's on the first PR. This is not to say that we
can't ever move forward but it should be noted that all breaking chang
Hi Robert,
That's fair and I agree: the story will be different when Polaris
1.0.0 will be out. From an end-user, it makes perfect sense.
As the 0.9.x branch exists, from an integrator standpoint (people
building something on top of the 0.9.0 branch), we can consider
breaking changes compar
Hey guys,
since there are already some other discussions going on, I want to also
start one about breaking changes.
IMHO a breaking change is a change that (not 100% formally correct:)
requires action from the user and/or removes functionality and/or
changes public API and/or the
20 matches
Mail list logo
