final
>> state of
>> > the branch, not the intermediate states. In case you need some changes
>> to
>> > fix the build, make sure to re-synchronize the source branch with the
>> > target branch, especially in case the changes are not done on the same
&g
done on the same
> day
> > because the Camel branches are modified very frequently and each change
> can
> > potentially be in conflicts with yours.
> > >
> > > it is a quite cumbersome approach but I don't see any safer way.
> > >
> > > Regards,
>
____________________
> > From: Otavio Rodolfo Piske
> > Sent: Thursday, June 22, 2023 08:53
> > To: dev@camel.apache.org
> > Subject: Re: Some thoughts on bisecting Camel and our git commit
> practices
> >
> > Hi,
> >
> > Release-t
oach but I don't see any safer way.
Regards,
Nicolas
From: Otavio Rodolfo Piske
Sent: Thursday, June 22, 2023 08:53
To: dev@camel.apache.org
Subject: Re: Some thoughts on bisecting Camel and our git commit practices
Hi,
Release-tagged commits don't
y, June 22, 2023 08:53
To: dev@camel.apache.org
Subject: Re: Some thoughts on bisecting Camel and our git commit practices
Hi,
Release-tagged commits don't help here. The whole point of bisecting is
finding out precisely which commit introduced a certain behavior or bug, so
that I and
Hi,
Release-tagged commits don't help here. The whole point of bisecting is
finding out precisely which commit introduced a certain behavior or bug, so
that I and other committers can diagnose, document and fix the problem.
It's not possible to do that effectively with just release-tagged commits.
Hi Otavio,
the codebase does not have the release quality
after each commit. Test-driven development could
even invite devs to separately commit failing tests
as a proof they are effective.
On contrary the release-tagged commits should
be safe. Would not help you to focus
on the release-tagged co
