Re: [PROPOSAL] Managing branches for future releases

Peter Kovacs wrote: Am Samstag, den 28.10.2017, 00:40 +0200 schrieb Andrea Pescetti: this thread was actually to address the problem with actually changing release numbers in code, nothing else. It does not adress the problem with release models. It works only around them. Is there a bug

Re: [PROPOSAL] Managing branches for future releases

Am Freitag, den 27.10.2017, 23:36 +0200 schrieb Marcus: > > sorry, but yes. > > At the moment I've not the time and mood to read and understand such > long mails. So, please don't expect an answer from me. I see. I am sorry. I will keep then my Ideas to me. Do them if I have time, suggest if I

Re: [PROPOSAL] Managing branches for future releases

Am Samstag, den 28.10.2017, 00:40 +0200 schrieb Andrea Pescetti: > Peter Kovacs wrote: > > I hope I did not scare anyone with this lengthy explanation now. > > No, but it is just off-topic. This is partially my fault since > "Managing > branches" in the subject could be read as a proposal for a

Re: [PROPOSAL] Managing branches for future releases

Peter Kovacs wrote: I hope I did not scare anyone with this lengthy explanation now. No, but it is just off-topic. This is partially my fault since "Managing branches" in the subject could be read as a proposal for a branching model. But this is totally not the topic here. The issue here

Re: [PROPOSAL] Managing branches for future releases

Hi - I’ll bite on a discussion. Overall I think that we are mixing two different purposes. (1) Keeping track of what is or may be released. This is what the current scheme does well when we are on a branch and not so well when we are on trunk. (2) Managing the lifecycle of a particular

Re: [PROPOSAL] Managing branches for future releases

Am 27.10.2017 um 23:28 schrieb Peter Kovacs: Disclaimer: I do not claime that one solution is the ultimate solution over the other. But I would like to explain my approach as long as it takes until everybody says he understood what I am suggesting. Nothing more nothing less. No religeous war is

Re: [PROPOSAL] Managing branches for future releases

Disclaimer: I do not claime that one solution is the ultimate solution over the other. But I would like to explain my approach as long as it takes until everybody says he understood what I am suggesting. Nothing more nothing less. No religeous war is intended or whished from my side. end

Re: [PROPOSAL] Managing branches for future releases

Am 26.10.2017 um 07:03 schrieb Peter kovacs: Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus : Sure, it's not yet written in stop. But when we need to build it it has to be. Furthermore, when releasing from "test" or "release" or similar, what to do with these branches?

Re: [PROPOSAL] Managing branches for future releases

+1. Having a branch ready to roll is cheap insurance. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [PROPOSAL] Managing branches for future releases

On 26 Oct, Peter kovacs wrote: > > > Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus : >>Am 25.10.2017 um 20:50 schrieb Peter kovacs: >>> Why do you want to branch all the time with names that can change? I >>think it is an expensive way of getting flexibility. I suggest a

Re: [PROPOSAL] Managing branches for future releases

Just to be clear. I follow by all passionate argumentation, my vote goes to whatever Jim and Matthias decide. They do releases, and they earned the most kudos on that. I am in whatever makes them happy! I like meritocracy! Even if that leaves me rather at the edge in a lot of topics. All the

Re: [PROPOSAL] Managing branches for future releases

Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus : >Am 25.10.2017 um 20:50 schrieb Peter kovacs: >> Why do you want to branch all the time with names that can change? I >think it is an expensive way of getting flexibility. I suggest a more >abstract branches. >> >> Why not

Re: [PROPOSAL] Managing branches for future releases

Hi Andrea, all On 24/10/2017 21:25, Andrea Pescetti wrote: This will ensure that we can shift the focus to trunk while still keeping a branch that remains ready for a quick release if needed. If we are never in this situation, the next release will be from the current trunk and AOO415 will

Re: [PROPOSAL] Managing branches for future releases

Am 24.10.2017 um 22:25 schrieb Andrea Pescetti: I'm starting a short series of occasional posts to capture the current collective state of mind on the next release. I'll float them here for refinement or lazy consensus, and then we may want to reuse this text in wiki or blog posts to avoid

Re: [PROPOSAL] Managing branches for future releases

Am 25.10.2017 um 20:50 schrieb Peter kovacs: Why do you want to branch all the time with names that can change? I think it is an expensive way of getting flexibility. I suggest a more abstract branches. Why not have 4 permanent branches that are dev/trunc , test, hotfix and Release? Dev/trunc

Re: [PROPOSAL] Managing branches for future releases

On Tue, Oct 24, 2017 at 4:00 PM, Patricia Shanahan wrote: > > > On 10/24/2017 2:34 PM, Kay Schenk wrote: > >> >> On 10/24/2017 01:25 PM, Andrea Pescetti wrote: >> >>> I'm starting a short series of occasional posts to capture the current >>> collective state of mind on the next

Re: [PROPOSAL] Managing branches for future releases

Why do you want to branch all the time with names that can change? I think it is an expensive way of getting flexibility. I suggest a more abstract branches. Why not have 4 permanent branches that are dev/trunc , test, hotfix and Release? Dev/trunc would contain latest development. Test would

Re: [PROPOSAL] Managing branches for future releases

Am 25.10.2017 um 19:44 schrieb Marcus: > Am 25.10.2017 um 01:00 schrieb Patricia Shanahan: >> >> On 10/24/2017 2:34 PM, Kay Schenk wrote: >>> >>> On 10/24/2017 01:25 PM, Andrea Pescetti wrote: I'm starting a short series of occasional posts to capture the current collective state of mind

Re: [PROPOSAL] Managing branches for future releases

We all wish for more frequent, more major releases. 4.1.x is just a number... No one will report you to the International Software Police if the next release will be 4.1.5 and have ten times more bug fixes and a dozen new features :) On Tue, Oct 24, 2017 at 11:25 PM, Andrea Pescetti

Re: [PROPOSAL] Managing branches for future releases

Am 25.10.2017 um 01:00 schrieb Patricia Shanahan: On 10/24/2017 2:34 PM, Kay Schenk wrote: On 10/24/2017 01:25 PM, Andrea Pescetti wrote: I'm starting a short series of occasional posts to capture the current collective state of mind on the next release. I'll float them here for refinement

Re: [PROPOSAL] Managing branches for future releases

+1 so we can also show to be ready to fix important bugs in time. this is also a statement to the community Regards Mechtilde Am 25.10.2017 um 01:00 schrieb Patricia Shanahan: > > > On 10/24/2017 2:34 PM, Kay Schenk wrote: >> >> On 10/24/2017 01:25 PM, Andrea Pescetti wrote: >>> I'm

Re: [PROPOSAL] Managing branches for future releases

On 10/24/2017 2:34 PM, Kay Schenk wrote: On 10/24/2017 01:25 PM, Andrea Pescetti wrote: I'm starting a short series of occasional posts to capture the current collective state of mind on the next release. I'll float them here for refinement or lazy consensus, and then we may want to reuse

Re: [PROPOSAL] Managing branches for future releases

Kay Schenk wrote: Would it be more clear to just remove the AOO415 branch and only re-instate it if needed (hopefully not). No, it wouldn't. See https://bz.apache.org/ooo/show_bug.cgi?id=127552 - there is a series of changes that need to be done for the release number bump. It's better to

Re: [PROPOSAL] Managing branches for future releases

On 10/24/2017 01:25 PM, Andrea Pescetti wrote: I'm starting a short series of occasional posts to capture the current collective state of mind on the next release. I'll float them here for refinement or lazy consensus, and then we may want to reuse this text in wiki or blog posts to avoid