Le 09/05/2024 à 13:21, Jacques Le Roux a écrit :
Hi Michael,
Inline again
Le 08/05/2024 à 21:00, Jacques Le Roux a écrit :
3. suddenly there was a mass of new PR's which were merged in a hurry
unneccesarily (my personal point of view), with some corrections soon after
4. 3. blocks 1. even
Hi Michael,
Inline again
Le 08/05/2024 à 21:00, Jacques Le Roux a écrit :
3. suddenly there was a mass of new PR's which were merged in a hurry
unneccesarily (my personal point of view), with some corrections soon after
4. 3. blocks 1. even further now because those changes are not
Ah, last but not least: I think we should at least wait for Freemarker 2.3.33 that we successfully tested on demo. The vote should be soon, hence the
release.
Le 08/05/2024 à 20:47, Jacques Le Roux a écrit :
Thanks to clarify Michael,
Inline when needed...
Le 08/05/2024 à 13:59, Michael
Thanks to clarify Michael,
Inline when needed...
Le 08/05/2024 à 13:59, Michael Brohl a écrit :
Hi everyone,
my main point for having a roadmap and (if necessary) freezing trunk (for a short time) before creating a release branch in the future was to avoid
the situation we have now:
1. we
Thanks for confirming
Le 08/05/2024 à 15:45, Pranay Pandey a écrit :
Hi Jacques,
Yeah, I wanted to say that. As long as we are sure of test coverage, all
the critical paths are working.
Best regards,
Pranay Pandey
On Tue, 7 May 2024 at 22:11, Jacques Le Roux
wrote:
Ha sorry Pranay,
I
Hi Jacques,
Yeah, I wanted to say that. As long as we are sure of test coverage, all
the critical paths are working.
Best regards,
Pranay Pandey
On Tue, 7 May 2024 at 22:11, Jacques Le Roux
wrote:
> Ha sorry Pranay,
>
> I did not get your point, I guess you were discussing before frezzing
Hi Michael,
Yeah, that makes a lot of sense to have a structure in place for sure.
Best regards,
Pranay Pandey
On Wed, 8 May 2024 at 17:30, Michael Brohl wrote:
> Hi everyone,
>
> my main point for having a roadmap and (if necessary) freezing trunk
> (for a short time) before creating a
Hi everyone,
my main point for having a roadmap and (if necessary) freezing trunk
(for a short time) before creating a release branch in the future was to
avoid the situation we have now:
1. we agreed to create a new release branch some time ago
2. there were some open tasks which blocked
I totally agree, our enemy is regression and we should be very sure to avoid it.
Le 07/05/2024 à 17:19, Pranay Pandey a écrit :
Hi Daniel,
I am in favor of creating a new release.
After we create a new release, IMO we shouldn't be committing any new
features there.
This is critical that we
Ha sorry Pranay,
I did not get your point, I guess you were discussing before frezzing the
release branch, right?
Then of course we can't guarantee to have fixed all known bugs.
Only blocker bugs (decided by the reporter and discussed if needed) and of
course security bugs are blocking a
Le 07/05/2024 à 17:01, Daniel Watford a écrit :
Hi Jacques,
I'm sorry, but I can't quite parse your question, 'What is the
difference...'. Could you restate it another way?
Simple, what is the process so far?
We freeze the trunk into a release branch, says 24.xx in our case
.05 seems short
Hi Pranay,
OK, but then only that? So far we backported any bug. So we would release a
branch with bugs in?
Le 07/05/2024 à 16:42, Pranay Pandey a écrit :
Hi Jacques,
what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the process
level.
Best
Hi Daniel,
I am in favor of creating a new release.
After we create a new release, IMO we shouldn't be committing any new
features there.
This is critical that we limit the scope of release with ongoing
development in the trunk.
Best regards,
Pranay Pandey
On Tue, 7 May 2024 at 20:31, Daniel
Hi Jacques,
I'm sorry, but I can't quite parse your question, 'What is the
difference...'. Could you restate it another way?
Are you asking what the difference is between enforcing a feature-freeze on
trunk versus continuing to allow all changes to trunk whilst having a
feature-freeze on a
Hi Jacques,
what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the process
level.
Best regards,
Pranay Pandey
On Tue, 7 May 2024 at 19:48, Jacques Le Roux
wrote:
> What is the difference between freezing the trunk in a release-24.xx where
>
What is the difference between freezing the trunk in a release-24.xx where the rule is no improvements but if a consensus agrees with? In other words,
apart exceptions only bugs and not only blockers,as we did so far and the "new" proposition? Do we really wants to backport only blockerbugs? And
Dear Daniel,
Thank you for outlining the proposed release strategy for OFBiz. I liked
the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.
I agree with Michael's proposal that targeting a release while working on
the trunk is worth
Hello all,
I'm a little confused by what the differences in opinions actually are in
this thread. I think this is because the differences are minor and we are
probably close to an agreement on how to proceed.
Although there are not many of us involved in this conversation, it seems
there is a
Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :
BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations?
BTW, to avoid to speak in the void. Again, what are those tasks precisely? And
WHAT are their situations?
Sorry, typo
BTW, to avoid to speak in the void. Again, what are those tasks precisely? And
that are their situations?
Le 06/05/2024 à 18:24, Jacques Le Roux a écrit :
Hi Stephen,
As I can see it, because of the number of people really involved in such tasks.
Jacques
Le 06/05/2024 à 17:45, Stephen
Hi Stephen,
As I can see it, because of the number of people really involved in such tasks.
Jacques
Le 06/05/2024 à 17:45, Stephen Davidson a écrit :
Good afternoon.
Maybe I am missing something, but why can't WIP be executed finished &
stabilized on the Release Branch and then merged to
Good afternoon.
Maybe I am missing something, but why can't WIP be executed finished &
stabilized on the Release Branch and then merged to Trunk?
Regards,
Steve
On 5/6/24 04:07, Jacques Le Roux wrote:
Hi,
We should 1st clearly identify WIPs in trunk and at which stage they
are each.
We
Hi,
We should 1st clearly identify WIPs in trunk and at which stage they are each.
We can't wait and complicate the situation before that.
Jacques
Le 06/05/2024 à 10:36, gil.portenseigne a écrit :
Hi,
I feel like Michael, when there are 'in progress' work in trunk, when we
create a release
Hi,
I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).
But delaying release is not good when we look at the name of our last
release that show
Hello,
Why don't create the release branch now ?
Nicolas
Le 21/04/2024 à 15:49, Michael Brohl a écrit :
Hi everyone,
we agreed to work towards a stabilizing trunk to be able to create a
24.x release branch, which means we have to thoroughly decide which
changes should go into trunk. There
Le 22/04/2024 à 16:12, Jacques Le Roux a écrit :
Without getting into details, I tend to disagree with your propositions.
I start writing that. Maybe I should rather have started by saying that I don't
understand why we should change our (simple) way of doing.
Hi Guys,
Without getting into details, I tend to disagree with your propositions. I
can't see why we would change our very simple way of doing.
When we freeze a branch, the activity can continue on trunk. It does not
interfere with the new release branch.
The only variable is the period we
Hi Michael,
I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.
I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we
Sounds good to me!!
I wanted to propose a change in process regarding the stabilization of code
releases.
Instead of restricting commits directly to the trunk, I suggest creating a
branch named "24.04" or "24.05" (depending on the release version)
specifically for stabilization purposes. This
Hi everyone,
we agreed to work towards a stabilizing trunk to be able to create a
24.x release branch, which means we have to thoroughly decide which
changes should go into trunk. There are currently lots of changes going
into trunk with PR's created and rapidly be merged into the codebase.
30 matches
Mail list logo
