You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andrea Pescetti <pe...@apache.org> on 2017/10/24 20:25:44 UTC
[PROPOSAL] Managing branches for future releases
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 repeating the same concepts over and over.
Let's start with branches.
We all wish 4.1.4 to be the last 4.1.x release.
We currently have an AOO415 branch at
http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
branch will result in a release ONLY if we have some important bug fixes
to release and trunk is not ready yet. No new features, even small
enhancements, are added to it. No commits to AOO415 happen without
appropriate mailing list discussions (dev or security, depending on cases).
Trunk is where all development happens. It will be branched for a new
release (like, an AOO420 branch - name still provisional) when the code
is mature: beta or even RC. Until then, we simply keep working on trunk
as we are doing now.
In case we need to commit to a branch, any changes are still committed
to trunk first and then merged to branches using SVN merge in all
situations when this is possible (i.e., when there are no merge
conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
have to make sure that trunk contains all fixes done there (or
equivalent in case of conflicts) and, done that, we commit to AOO415
only if:
1. The fix is important and agreed upon on the relevant list
2. The commit is done with "svn merge" starting from a trunk commit
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 never result in a release.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Peter kovacs <pe...@apache.org>.
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 best
Peter
Am 26. Oktober 2017 00:18:25 MESZ schrieb Marcus <ma...@wtnet.de>:
>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 repeating the same concepts over and
>over.
>>
>> Let's start with branches.
>>
>> We all wish 4.1.4 to be the last 4.1.x release.
>>
>> We currently have an AOO415 branch at
>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>branch
>> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
>> branch will result in a release ONLY if we have some important bug
>fixes
>> to release and trunk is not ready yet. No new features, even small
>> enhancements, are added to it. No commits to AOO415 happen without
>> appropriate mailing list discussions (dev or security, depending on
>cases).
>>
>> Trunk is where all development happens. It will be branched for a new
>
>> release (like, an AOO420 branch - name still provisional) when the
>code
>> is mature: beta or even RC. Until then, we simply keep working on
>trunk
>> as we are doing now.
>>
>> In case we need to commit to a branch, any changes are still
>committed
>> to trunk first and then merged to branches using SVN merge in all
>> situations when this is possible (i.e., when there are no merge
>> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
>
>> have to make sure that trunk contains all fixes done there (or
>> equivalent in case of conflicts) and, done that, we commit to AOO415
>> only if:
>> 1. The fix is important and agreed upon on the relevant list
>> 2. The commit is done with "svn merge" starting from a trunk commit
>>
>> 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 never result in a release.
>
>"First trunk, then the branch(es)" is not new. I think we are working
>already in this way. But just to make it clear.
>
>so, to keep it short:
>I like the proposal.
>
>Marcus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Marcus <ma...@wtnet.de>.
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 repeating the same concepts over and over.
>
> Let's start with branches.
>
> We all wish 4.1.4 to be the last 4.1.x release.
>
> We currently have an AOO415 branch at
> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
> branch will result in a release ONLY if we have some important bug fixes
> to release and trunk is not ready yet. No new features, even small
> enhancements, are added to it. No commits to AOO415 happen without
> appropriate mailing list discussions (dev or security, depending on cases).
>
> Trunk is where all development happens. It will be branched for a new
> release (like, an AOO420 branch - name still provisional) when the code
> is mature: beta or even RC. Until then, we simply keep working on trunk
> as we are doing now.
>
> In case we need to commit to a branch, any changes are still committed
> to trunk first and then merged to branches using SVN merge in all
> situations when this is possible (i.e., when there are no merge
> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
> have to make sure that trunk contains all fixes done there (or
> equivalent in case of conflicts) and, done that, we commit to AOO415
> only if:
> 1. The fix is important and agreed upon on the relevant list
> 2. The commit is done with "svn merge" starting from a trunk commit
>
> 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 never result in a release.
"First trunk, then the branch(es)" is not new. I think we are working
already in this way. But just to make it clear.
so, to keep it short:
I like the proposal.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Pedro Lino <pe...@mailbox.org>.
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 never result in a release.
+1
One of the major criticisms to AOO is that it took too long to fix some
security issue and left the "community" at risk. So it is a good plan to
have a branch in ready-to-launch state.
Pedro
Re: [PROPOSAL] Managing branches for future releases
Posted by esh1907 <es...@gmail.com>.
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 <pe...@apache.org>
wrote:
>
>
> We all wish 4.1.4 to be the last 4.1.x release.
>
>
Re: [PROPOSAL] Managing branches for future releases
Posted by Dave Fisher <da...@comcast.net>.
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 release. You propose a fairly common step model. I think that we go to a release branch sometime in your TEST.
We have a very complex build process where a little change on Windows might make the Unix or Mac build unstable.
I would propose that we operate more like so.
We have two types of branches.
(A) Release branches as we do now. These have Test, Release and Maintenance phases. In this case all of our 4.1.X branches including 4.1.5 are in maintenance.
(B) Feature branches would be new for AOO. In these branches we co-operate between DEV and Test phases. We work out build issues on each platform for the feature in isolation. Community testers can be given test builds, etc.
Branches are merged to Trunk or a Release at certain times in the lifecycle. When a merge is done a phase of TEST is required on the result.
Example.
(1) Create an SDBC feature branch from trunk.
(2) Create a 4.2.0 release branch from trunk.
(3) Create an update Java feature branch from trunk.
(4) Develop and test the Java update.
(5) Merge the Java feature branch to SDBC feature branch.
(6) Develop and test the SDBC feature branch.
(7) Merge the SDBC feature branch to trunk and TEST.
(8) Merge trunk to 4.2.0 release branch.
(9) Test the 4.2.0 release branch.
(10) Release 4.2.0.
Other feature branches could be:
- Sign the Mac Application with an Apple Developer key.
- Bullet proof Windows Installer to reject spammers.
Regards,
Dave
> On Oct 27, 2017, at 2:28 PM, Peter Kovacs <le...@posteo.de> wrote:
>
> 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 disclaimer.
>
> Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
>>> Why do you think it is a problem to go by state?
>>
>> I cannot see what is behind the names. "test" - from what? Is it
>> still
>> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
>> for
>> everyone.
> It is a life cyle model. You do not need to know a release number.
> A release number does tell nothing.
> A life Cycle state tells you exactly which state the Product is in.
>
> DEV: It is under development. The code can have serious bugs, break.
> But can also have the newst feature that may only partial implemented.
> In general the code is good enough that it compiles on the dev
> machines.
>
> TEST: Often revered to unstable.
> The Code is in a feature freeze. It recieves bugfixes, that stabilize
> the Code until it reaches the maturity that we expect from it. TEST
> unlike DEV takes picks only new features up at a certain time.
> Usually after the Code has reached a maturity state.
>
>
> Release: often reverred to Stable.
> The branch that only contains best possible code, to have transperency.
> It also is the source to give people a clear state what is changing
> from one change to the next.
>
> hotfix, means maintenance:
> This should be an exception. When we feel we need to fix something on
> release level, because we missed a bug in the maturity phase.
>
> It is a complete different development model. We can use Release
> numbers to name a specific cycle. But we control the code not by that
> number. We could give it also a Name like "Eternia Version" Would have
> the same meaning.
>
> Let me draw a picture, a fantasy example for illustration:
> Time -------->
> by live cycle:
> 4.1.4 4.1.5
> hotfix -x--x---+ +--x--x---x+ 4.2.0
> Release --------V------------+----------V---------------A-------------
> born:4.2.0 every x here a bugfix born:5.0.0
>
> Test -----------A------x---x-----x--x--x---x----x--x-+-A---x--x---x-
> Dev ----x----x-+-x--------x------------x---------x--V-+------------
> PSQL1&2 OOXML Googlestuff Root-lib | fix integration
> video feature
>
> by release Number:
> PSQL1&2 OOXML Googlestuff Root-lib Sience-interface
> trunc -x--x----x-+-x----x---x-----x--x--xx--x----x-x----+-+--x--x---x-
> 4.1.4 -x--x---+
> 4.1.5 +--x--x---x+
> 4.2.0 +-x----x---x-----x--x--x---x----x--x-+
> 5.0.0 +---x--x---x-
>
> The above example does not break any history. You have a clear state,
> on the advancement of the code.
> You can compare at any given time the code (I.E. using fisheye). And
> you can archieve by time.
> In the above model we restrict sharing of changes to certain moments of
> time. So the state is always defined.
>
> The lower example due the nature of the approach you have in each
> branch a single "fork". The advantage is that you can maintain each
> Version from the other. You can also reintegrate a external Fork based
> on someotherworks with ease.
> But comparing branches is not guaranteed, since they are disconected to
> each other. Both could be potential be maintained.
> Plus at any moment you can have bugs or features introduce to your
> branch, as you like, but probably it is not intended.
> Archiving is done by time on trunc, and by release on branche. Getting
> time and branch together again might be difficult. Maybe we could
> archieve both if we go by time and branch so only complete branches are
> saved.
>
> Of course a lot of things assumed here is pure agreement and disciplin.
> However I do not see any benefit to us in maintaining each version as
> an own branch, since we do not want to maintain the branches.
> As you see in the Picture.
>
> It is the methology of thinging. In released based production it is of
> course dreadfull to mix branches, because you do your controling by
> release numbering.
> In my suggested model you do not controlling by a release number but by
> state of the code. by which we push our core value "stability over
> Feature" into our steering centre.
>
> Also we would like to have almost none hotfixes. Maybe they can be done
> as branches seperatly since there it can realy get confusing which
> state a hotfix branch is in. And we need it only for ensuring that fix
> does not break anything else. So normaly hoitfix brnches have a short
> live period.
>
> Also some thoughts about Release number:
> The methology of Agile programming is often reduced to release often.
> Which may translate to the idea that release number needs to rattle up.
> (Firefox anyone?)
> I think it is a stupid Idea, and does not work. It comes from an aera
> when Versionening systems were none existand.
> Does anyone use time dates to version his documents on disk?
> It is the same system just less abstract.
>
> I think we need to pull the community together. If there are companies
> out there using open office, we must convince them to integrate our
> process of updating in their workstream.
> Only then we will get business interest, and an effective drive on a
> clear open source model.
>
> Relase Model can give a business entity to skipp specifying their
> requirements on us and take the lazy method in trying to stick to the
> Version they have. A "rolling release" discourages this.
>
> I also would like to add as an argument against rolling modell, that
> our build environment and our publish procedures are closely tied to
> the release model.
> To switch the modell is probably not an easy thing to do.
> Things I have noted from the discussion:
> - Automated builds is super important I think in a rolling modell.
> - Version number is tied in multiple places, which is awkward at best.
> - Dictionaries are not covered in the modell. And I am not sure how
> they move with that, because they have their own cycle.
> If we could make code more intependant from the dictionaries, we could
> let them swing independently from each other, which would be super
> cool. but that would mean that an dictionary update is done compile
> free.
> - We must get better at updateing an installed version. I think the
> need to reset or delete the profile is in general not good.
>
> So I hope this rather lengthy email is explaining all stuff.
> I hope I did not scare anyone with this lengthy explanation now.
>
> All the best
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: [PROPOSAL] Managing branches for future releases
Posted by Peter Kovacs <le...@posteo.de>.
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 have a solution. suggest only non scary things.
>
> If the majority of the community is supporting your
> proposal/suggestion/..., then fine.
Dont think there is a support, for the usual reasons.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Marcus <ma...@wtnet.de>.
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 intended or whished from my side.
> end disclaimer.
>
> Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
>>> Why do you think it is a problem to go by state?
>>
>> I cannot see what is behind the names. "test" - from what? Is it
>> still
>> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
>> for
>> everyone.
>
> [ looooooong mail]
>
> So I hope this rather lengthy email is explaining all stuff.
> I hope I did not scare anyone with this lengthy explanation now.
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.
If the majority of the community is supporting your
proposal/suggestion/..., then fine.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Andrea Pescetti <pe...@apache.org>.
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 report for the Problem?
https://bz.apache.org/ooo/show_bug.cgi?id=127552 but the right way would
be to simply script it, so using the occasion for performing that
specific set of changes, but also for improving our tools so that we can
execute a script to achieve the same effect.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Peter Kovacs <le...@posteo.de>.
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 branching
> model. But this is totally not the topic here.
I am not objecting it.
>
> The issue here is very simple and unrelated to the branching model.
> The
> issue is: if you want a release to be named "4.1.4" you have to
> update
> dozens of files to get it done properly, it is not a one-line change
> to
> set "VERSION = 4.1.4" as some would expect. This is stupid, should
> be
> scripted, caused two rebuilds of binaries in 4.1.4 due to
> distraction.
We have a lots of convenieance Programming antipatterns in the code.
I dont like those, because to me they are very much unconvenient.
This should be handled by the build system.
>
> If we have to release 4.1.5 (not foreseen at the moment) we will want
> to
> spend our time in actually fixing the bugs, and not in the painful
> update of release numbers here and there. If we do it now, and maybe
> take the occasion for scripting it, we won't risk useless delays.
>
> This is all I wanted to say, and I hope it's clear now.
>
> We could go on for ages discussing branching models, but the point
> of
> 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 report for the Problem?
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Andrea Pescetti <pe...@apache.org>.
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 is very simple and unrelated to the branching model. The
issue is: if you want a release to be named "4.1.4" you have to update
dozens of files to get it done properly, it is not a one-line change to
set "VERSION = 4.1.4" as some would expect. This is stupid, should be
scripted, caused two rebuilds of binaries in 4.1.4 due to distraction.
If we have to release 4.1.5 (not foreseen at the moment) we will want to
spend our time in actually fixing the bugs, and not in the painful
update of release numbers here and there. If we do it now, and maybe
take the occasion for scripting it, we won't risk useless delays.
This is all I wanted to say, and I hope it's clear now.
We could go on for ages discussing branching models, but the point of
this thread was actually to address the problem with actually changing
release numbers in code, nothing else.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Peter Kovacs <le...@posteo.de>.
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 disclaimer.
Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus:
> > Why do you think it is a problem to go by state?
>
> I cannot see what is behind the names. "test" - from what? Is it
> still
> for 4.1.x or the new 4.2.0 or what? I really think it is not clear
> for
> everyone.
It is a life cyle model. You do not need to know a release number.
A release number does tell nothing.
A life Cycle state tells you exactly which state the Product is in.
DEV: It is under development. The code can have serious bugs, break.
But can also have the newst feature that may only partial implemented.
In general the code is good enough that it compiles on the dev
machines.
TEST: Often revered to unstable.
The Code is in a feature freeze. It recieves bugfixes, that stabilize
the Code until it reaches the maturity that we expect from it. TEST
unlike DEV takes picks only new features up at a certain time.
Usually after the Code has reached a maturity state.
Release: often reverred to Stable.
The branch that only contains best possible code, to have transperency.
It also is the source to give people a clear state what is changing
from one change to the next.
hotfix, means maintenance:
This should be an exception. When we feel we need to fix something on
release level, because we missed a bug in the maturity phase.
It is a complete different development model. We can use Release
numbers to name a specific cycle. But we control the code not by that
number. We could give it also a Name like "Eternia Version" Would have
the same meaning.
Let me draw a picture, a fantasy example for illustration:
Time -------->
by live cycle:
4.1.4 4.1.5
hotfix -x--x---+ +--x--x---x+ 4.2.0
Release --------V------------+----------V---------------A-------------
born:4.2.0 every x here a bugfix born:5.0.0
Test -----------A------x---x-----x--x--x---x----x--x-+-A---x--x---x-
Dev ----x----x-+-x--------x------------x---------x--V-+------------
PSQL1&2 OOXML Googlestuff Root-lib | fix integration
video feature
by release Number:
PSQL1&2 OOXML Googlestuff Root-lib Sience-interface
trunc -x--x----x-+-x----x---x-----x--x--xx--x----x-x----+-+--x--x---x-
4.1.4 -x--x---+
4.1.5 +--x--x---x+
4.2.0 +-x----x---x-----x--x--x---x----x--x-+
5.0.0 +---x--x---x-
The above example does not break any history. You have a clear state,
on the advancement of the code.
You can compare at any given time the code (I.E. using fisheye). And
you can archieve by time.
In the above model we restrict sharing of changes to certain moments of
time. So the state is always defined.
The lower example due the nature of the approach you have in each
branch a single "fork". The advantage is that you can maintain each
Version from the other. You can also reintegrate a external Fork based
on someotherworks with ease.
But comparing branches is not guaranteed, since they are disconected to
each other. Both could be potential be maintained.
Plus at any moment you can have bugs or features introduce to your
branch, as you like, but probably it is not intended.
Archiving is done by time on trunc, and by release on branche. Getting
time and branch together again might be difficult. Maybe we could
archieve both if we go by time and branch so only complete branches are
saved.
Of course a lot of things assumed here is pure agreement and disciplin.
However I do not see any benefit to us in maintaining each version as
an own branch, since we do not want to maintain the branches.
As you see in the Picture.
It is the methology of thinging. In released based production it is of
course dreadfull to mix branches, because you do your controling by
release numbering.
In my suggested model you do not controlling by a release number but by
state of the code. by which we push our core value "stability over
Feature" into our steering centre.
Also we would like to have almost none hotfixes. Maybe they can be done
as branches seperatly since there it can realy get confusing which
state a hotfix branch is in. And we need it only for ensuring that fix
does not break anything else. So normaly hoitfix brnches have a short
live period.
Also some thoughts about Release number:
The methology of Agile programming is often reduced to release often.
Which may translate to the idea that release number needs to rattle up.
(Firefox anyone?)
I think it is a stupid Idea, and does not work. It comes from an aera
when Versionening systems were none existand.
Does anyone use time dates to version his documents on disk?
It is the same system just less abstract.
I think we need to pull the community together. If there are companies
out there using open office, we must convince them to integrate our
process of updating in their workstream.
Only then we will get business interest, and an effective drive on a
clear open source model.
Relase Model can give a business entity to skipp specifying their
requirements on us and take the lazy method in trying to stick to the
Version they have. A "rolling release" discourages this.
I also would like to add as an argument against rolling modell, that
our build environment and our publish procedures are closely tied to
the release model.
To switch the modell is probably not an easy thing to do.
Things I have noted from the discussion:
- Automated builds is super important I think in a rolling modell.
- Version number is tied in multiple places, which is awkward at best.
- Dictionaries are not covered in the modell. And I am not sure how
they move with that, because they have their own cycle.
If we could make code more intependant from the dictionaries, we could
let them swing independently from each other, which would be super
cool. but that would mean that an dictionary update is done compile
free.
- We must get better at updateing an installed version. I think the
need to reset or delete the profile is in general not good.
So I hope this rather lengthy email is explaining all stuff.
I hope I did not scare anyone with this lengthy explanation now.
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Marcus <ma...@wtnet.de>.
Am 26.10.2017 um 07:03 schrieb Peter kovacs:
> Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <ma...@wtnet.de>:
>>
>> 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? I hope you do not suggest "then we can recycle
>> them and reuse for the next build". ;-)
> Why do you think it is a problem to go by state?
I cannot see what is behind the names. "test" - from what? Is it still
for 4.1.x or the new 4.2.0 or what? I really think it is not clear for
everyone.
And again:
Never, never, ever reuse a branch that has seen a release. You will
destroy the history. In the worst case you will loose the overview and
therefore loose time when you actually don't have it.
Creating a new branch just after we have released a version is fast and
cheap.
Marcus
>>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
>> <ma...@wtnet.de>:
>>>> 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 or lazy consensus, and then we may want to
>>>> reuse
>>>>>>> this text in wiki or blog posts to avoid repeating the same
>>>> concepts
>>>>>>> over and over.
>>>>>>>
>>>>>>> Let's start with branches.
>>>>>>>
>>>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>>>
>>>>>>> We currently have an AOO415 branch at
>>>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4).
>> The
>>>>
>>>>>>> AOO415 branch will result in a release ONLY if we have some
>>>> important
>>>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>>>> even small enhancements, are added to it. No commits to AOO415
>>>> happen
>>>>>>> without appropriate mailing list discussions (dev or security,
>>>>>>> depending on cases).
>>>>>>>
>>>>>>> Trunk is where all development happens. It will be branched for a
>>>> new
>>>>>>> release (like, an AOO420 branch - name still provisional) when
>> the
>>>>>>> code is mature: beta or even RC. Until then, we simply keep
>> working
>>>>
>>>>>>> on trunk as we are doing now.
>>>>>>>
>>>>>>> In case we need to commit to a branch, any changes are still
>>>>>>> committed to trunk first and then merged to branches using SVN
>>>> merge
>>>>>>> in all situations when this is possible (i.e., when there are no
>>>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>> clear,
>>>> so
>>>>>>> we'll have to make sure that trunk contains all fixes done there
>>>> (or
>>>>>>> equivalent in case of conflicts) and, done that, we commit to
>>>> AOO415
>>>>>>> only if:
>>>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>>>> 2. The commit is done with "svn merge" starting from a trunk
>> commit
>>>>>>>
>>>>>>> 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 never result in a release.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Andrea.
>>>>>>
>>>>>> Would it be more clear to just remove the AOO415 branch and only
>>>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>>>> AOO415 that wasn't included in AOO414.
>>>>>>
>>>>>
>>>>> The decision to keep the 4.1.5 branch around came out of a
>> discussion
>>>> on
>>>>> the security mailing list. The potential problem is that someday we
>>>> may
>>>>> be faced with a bug for which we need to get a fix out into the
>> field
>>>> as
>>>>> soon as possible.
>>>>>
>>>>> Because of the sheer size of AOO, it takes time to get set up for a
>>>>> release. The idea is to do as much as we can to prepare without
>>>>> committing to a release. I have a check-out of AOO415 built. As the
>>>>> version number changes get incorporated I'll update and rebuild.
>> Not
>>>>> having to wait for the branch to be prepared, check it out, and do
>> a
>>>>> full build reduces by about a day the time it would take from
>> knowing
>>>> a
>>>>> fix to having it built, tested, and checked in.
>>>>>
>>>>> I would like to make this an on-going policy. As soon as we ship
>>>> 4.2.0,
>>>>> we remove the AOO415 branch but create AOO421, identical except for
>>>>> version numbers to AOO420, ready in case of an emergency fix.
>>>>
>>>> +1
>>>> This is an good and cheap idea to speed things up.
>>>>
>>>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Don Lewis <tr...@apache.org>.
On 26 Oct, Peter kovacs wrote:
>
>
> Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <ma...@wtnet.de>:
>>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 would contain latest development.
>>> Test would contain the latest release candidate that gets prepared.
>>It bases of from dev and propagates to release.
>>> Hotfix is the one that bases on release and propagates back to
>>release branch.
>>> With this schema you have an abstract way in doing the same thing
>>without the limitation of naming.
>>
>>sorry but this is totally confusing.
>>
>>> We could even post vote result into comments. When propagate version
>>to release. Also we can decide on release name at the latest possible
>>moment.
>>
>>Deciding on the name (or better said version numnber) when the build
>>is
>>
>>nearly finished dooesn't make sense. We need to know what we are
>>working on.
>>
>>> It would be less confusing especially if we rename a release. (4.2.0
>>is not final decided. But we may now have branch. Or we wait until we
>>have decided but that would delay the result until we are done with
>>the naming.)
>>
>>There are only a few moments when we need to agree on a new version
>>number. The new release will be one of these. Currently it's 4.2.0 but
>>who knows.
> That's exactly what I mean. Our release cycles are slow. We have
> decided a year ago we stick to 4.2.0 but it was not final it seems.
> Better decide on the name when ready.
>>
>>Every bugfix release is a minor release. So, only the last number will
>>be increased.
> I think this is not critical. But decision 4.2.0 or 5.0.0 is more
> political then technical.
>
>>
>>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? I hope you do not suggest "then we can recycle
>>them and reuse for the next build". ;-)
> Why do you think it is a problem to go by state?
>
> I see the benefit that there is no need to delete 4.1.5 if we do not
> need it. We simply promote the code in the branch from release. Maybe
> state as a comment. Rebase to 4.2.0 release. Done.
> Also a new release is done the same way.
> No need for new branches and maybe explain people what's the release
> because release manager had no time to make a new branch.
We need at least as many branches as we have releases. If you try to
reuse a branch, then you will lose whatever history is associated with
it. We have branches for 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4, plus lots
more for older releases. That allows us to look at what is in each of
those releases as well as look back at the changes that were part of
those releases. Running the svn command to create a new branch isn't
the time consuming part. Most of the effort is spent on tweaking all
of the source files that contain version-specific information,
solenv/inc/minor.mk for one example. That would still have to be done
manually even if you try to reuse a branch.
svn doesn't have anything like git rebase. Even in git, rebase is
problematic. If you rebase a branch checked out from a remote
repository, git won't let you push it back. If you do a force push,
you'll hose anyone else who has a copy of that branch. They'll have to
delete their local copy of that branch and refetch. About the only way
to safely use rebase is to create a new local branch, rebase that, and
then push to create a new remote branch.
> Also I think for people. Testers will check out test or hot fix (Maybe
> maintenance is a better word). A someone who wants a release version
> simply checks out release branch. There is no need explaining anyone
> which one is the current release what is maintenance.
You really can't reuse hotfix branches, you have to generate unique
names for them. With a git-based workflow, you might want to create a
new branch to test a hotfix, and you can delete it after the fix has
been tested successfully and merged, but later creating a new branch
with the same name will cause problems. Anybody who has a copy of the
old version of that branch will run into problems when trying to pull
the new version because the history of the local and remote copies will
not match.
> It is error proove.
> Also if you think on auto builds. No maintenance. If you use version
> names you have to make sure that the release builder always points at
> release branch. That maintenance builder points on the current machine
> branch. There will be always manually tasks involved. And manuall
> means potential failures.
>
> Also if you think on our release cycles we have discussed.
> 1-2 years for feature release
> 1-2 additional maintenance. Maybe we do more maintenance.
>
> We will develop parallel in various branches.
>
> At least for maintenance and one for features. I assume we will stick
> to long freeze code times since quality is our concern.
We already sort of do that, trunk gets a mix of new features and
maintenance. Mostly the latter since there is a lot of maintenance
backlog and not enough developer cycles to spend on many new features.
Bug fixes if they are important enough get merged to the 4.1.x release
branches. At some point in the future, we'll create a 4.2.0 branch
which we will only get bug fixes from trunk, which will allow us to try
to make it stable enough for a 4.2.0 release.
> If we would like to use the classics open source release cycle to
> release often. I'd say version numbers are a good thing. Because we
> will have one development and release that in a cycle. But we talk not
> in this way. So I suggest we need a different way to manage our code.
>
> The method I suggest is used by SUSE document group. You can see that
> in their talk on FOSDEM 2017. At least the idea I have from them.
>>
>>Marcus
>>
>>
>>
>>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
>><ma...@wtnet.de>:
>>>> 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 or lazy consensus, and then we may want to
>>>> reuse
>>>>>>> this text in wiki or blog posts to avoid repeating the same
>>>> concepts
>>>>>>> over and over.
>>>>>>>
>>>>>>> Let's start with branches.
>>>>>>>
>>>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>>>
>>>>>>> We currently have an AOO415 branch at
>>>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4).
>>The
>>>>
>>>>>>> AOO415 branch will result in a release ONLY if we have some
>>>> important
>>>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>>>> even small enhancements, are added to it. No commits to AOO415
>>>> happen
>>>>>>> without appropriate mailing list discussions (dev or security,
>>>>>>> depending on cases).
>>>>>>>
>>>>>>> Trunk is where all development happens. It will be branched for
>>>>>a new
>>>>>>> release (like, an AOO420 branch - name still provisional) when
>>the
>>>>>>> code is mature: beta or even RC. Until then, we simply keep
>>working
>>>>
>>>>>>> on trunk as we are doing now.
>>>>>>>
>>>>>>> In case we need to commit to a branch, any changes are still
>>>>>>> committed to trunk first and then merged to branches using SVN
>>>> merge
>>>>>>> in all situations when this is possible (i.e., when there are no
>>>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>>clear,
>>>> so
>>>>>>> we'll have to make sure that trunk contains all fixes done there
>>>> (or
>>>>>>> equivalent in case of conflicts) and, done that, we commit to
>>>> AOO415
>>>>>>> only if:
>>>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>>>> 2. The commit is done with "svn merge" starting from a trunk
>>commit
>>>>>>>
>>>>>>> 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 never result in a release.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Andrea.
>>>>>>
>>>>>> Would it be more clear to just remove the AOO415 branch and only
>>>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>>>> AOO415 that wasn't included in AOO414.
>>>>>>
>>>>>
>>>>> The decision to keep the 4.1.5 branch around came out of a
>>discussion
>>>> on
>>>>> the security mailing list. The potential problem is that someday
>>>>>we may
>>>>> be faced with a bug for which we need to get a fix out into the
>>field
>>>> as
>>>>> soon as possible.
>>>>>
>>>>> Because of the sheer size of AOO, it takes time to get set up for
>>>>> a release. The idea is to do as much as we can to prepare without
>>>>> committing to a release. I have a check-out of AOO415 built. As
>>>>> the version number changes get incorporated I'll update and
>>rebuild. Not
>>>>> having to wait for the branch to be prepared, check it out, and do
>>a
>>>>> full build reduces by about a day the time it would take from
>>knowing
>>>> a
>>>>> fix to having it built, tested, and checked in.
>>>>>
>>>>> I would like to make this an on-going policy. As soon as we ship
>>>> 4.2.0,
>>>>> we remove the AOO415 branch but create AOO421, identical except
>>>>> for version numbers to AOO420, ready in case of an emergency fix.
>>>>
>>>> +1
>>>> This is an good and cheap idea to speed things up.
>>>>
>>>> Marcus
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>For additional commands, e-mail: dev-help@openoffice.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Peter kovacs <pe...@apache.org>.
Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <ma...@wtnet.de>:
>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 would contain latest development.
>> Test would contain the latest release candidate that gets prepared.
>It bases of from dev and propagates to release.
>> Hotfix is the one that bases on release and propagates back to
>release branch.
>> With this schema you have an abstract way in doing the same thing
>without the limitation of naming.
>
>sorry but this is totally confusing.
>
>> We could even post vote result into comments. When propagate version
>to release. Also we can decide on release name at the latest possible
>moment.
>
>Deciding on the name (or better said version numnber) when the build is
>
>nearly finished dooesn't make sense. We need to know what we are
>working on.
>
>> It would be less confusing especially if we rename a release. (4.2.0
>is not final decided. But we may now have branch. Or we wait until we
>have decided but that would delay the result until we are done with the
>naming.)
>
>There are only a few moments when we need to agree on a new version
>number. The new release will be one of these. Currently it's 4.2.0 but
>who knows.
That's exactly what I mean. Our release cycles are slow. We have decided a year ago we stick to 4.2.0 but it was not final it seems.
Better decide on the name when ready.
>
>Every bugfix release is a minor release. So, only the last number will
>be increased.
I think this is not critical. But decision 4.2.0 or 5.0.0 is more political then technical.
>
>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? I hope you do not suggest "then we can recycle
>them and reuse for the next build". ;-)
Why do you think it is a problem to go by state?
I see the benefit that there is no need to delete 4.1.5 if we do not need it.
We simply promote the code in the branch from release. Maybe state as a comment.
Rebase to 4.2.0 release. Done.
Also a new release is done the same way.
No need for new branches and maybe explain people what's the release because release manager had no time to make a new branch.
Also I think for people. Testers will check out test or hot fix (Maybe maintenance is a better word).
A someone who wants a release version simply checks out release branch. There is no need explaining anyone which one is the current release what is maintenance.
It is error proove.
Also if you think on auto builds. No maintenance. If you use version names you have to make sure that the release builder always points at release branch. That maintenance builder points on the current machine branch. There will be always manually tasks involved. And manuall means potential failures.
Also if you think on our release cycles we have discussed.
1-2 years for feature release
1-2 additional maintenance. Maybe we do more maintenance.
We will develop parallel in various branches.
At least for maintenance and one for features. I assume we will stick to long freeze code times since quality is our concern.
If we would like to use the classics open source release cycle to release often. I'd say version numbers are a good thing. Because we will have one development and release that in a cycle.
But we talk not in this way. So I suggest we need a different way to manage our code.
The method I suggest is used by SUSE document group. You can see that in their talk on FOSDEM 2017. At least the idea I have from them.
>
>Marcus
>
>
>
>> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus
><ma...@wtnet.de>:
>>> 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 or lazy consensus, and then we may want to
>>> reuse
>>>>>> this text in wiki or blog posts to avoid repeating the same
>>> concepts
>>>>>> over and over.
>>>>>>
>>>>>> Let's start with branches.
>>>>>>
>>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>>
>>>>>> We currently have an AOO415 branch at
>>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4).
>The
>>>
>>>>>> AOO415 branch will result in a release ONLY if we have some
>>> important
>>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>>> even small enhancements, are added to it. No commits to AOO415
>>> happen
>>>>>> without appropriate mailing list discussions (dev or security,
>>>>>> depending on cases).
>>>>>>
>>>>>> Trunk is where all development happens. It will be branched for a
>>> new
>>>>>> release (like, an AOO420 branch - name still provisional) when
>the
>>>>>> code is mature: beta or even RC. Until then, we simply keep
>working
>>>
>>>>>> on trunk as we are doing now.
>>>>>>
>>>>>> In case we need to commit to a branch, any changes are still
>>>>>> committed to trunk first and then merged to branches using SVN
>>> merge
>>>>>> in all situations when this is possible (i.e., when there are no
>>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>clear,
>>> so
>>>>>> we'll have to make sure that trunk contains all fixes done there
>>> (or
>>>>>> equivalent in case of conflicts) and, done that, we commit to
>>> AOO415
>>>>>> only if:
>>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>>> 2. The commit is done with "svn merge" starting from a trunk
>commit
>>>>>>
>>>>>> 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 never result in a release.
>>>>>>
>>>>>> Regards,
>>>>>> Andrea.
>>>>>
>>>>> Would it be more clear to just remove the AOO415 branch and only
>>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>>> AOO415 that wasn't included in AOO414.
>>>>>
>>>>
>>>> The decision to keep the 4.1.5 branch around came out of a
>discussion
>>> on
>>>> the security mailing list. The potential problem is that someday we
>>> may
>>>> be faced with a bug for which we need to get a fix out into the
>field
>>> as
>>>> soon as possible.
>>>>
>>>> Because of the sheer size of AOO, it takes time to get set up for a
>>>> release. The idea is to do as much as we can to prepare without
>>>> committing to a release. I have a check-out of AOO415 built. As the
>>>> version number changes get incorporated I'll update and rebuild.
>Not
>>>> having to wait for the branch to be prepared, check it out, and do
>a
>>>> full build reduces by about a day the time it would take from
>knowing
>>> a
>>>> fix to having it built, tested, and checked in.
>>>>
>>>> I would like to make this an on-going policy. As soon as we ship
>>> 4.2.0,
>>>> we remove the AOO415 branch but create AOO421, identical except for
>>>> version numbers to AOO420, ready in case of an emergency fix.
>>>
>>> +1
>>> This is an good and cheap idea to speed things up.
>>>
>>> Marcus
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Marcus <ma...@wtnet.de>.
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 would contain latest development.
> Test would contain the latest release candidate that gets prepared. It bases of from dev and propagates to release.
> Hotfix is the one that bases on release and propagates back to release branch.
> With this schema you have an abstract way in doing the same thing without the limitation of naming.
sorry but this is totally confusing.
> We could even post vote result into comments. When propagate version to release. Also we can decide on release name at the latest possible moment.
Deciding on the name (or better said version numnber) when the build is
nearly finished dooesn't make sense. We need to know what we are working on.
> It would be less confusing especially if we rename a release. (4.2.0 is not final decided. But we may now have branch. Or we wait until we have decided but that would delay the result until we are done with the naming.)
There are only a few moments when we need to agree on a new version
number. The new release will be one of these. Currently it's 4.2.0 but
who knows.
Every bugfix release is a minor release. So, only the last number will
be increased.
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? I hope you do not suggest "then we can recycle
them and reuse for the next build". ;-)
Marcus
> Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus <ma...@wtnet.de>:
>> 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 or lazy consensus, and then we may want to
>> reuse
>>>>> this text in wiki or blog posts to avoid repeating the same
>> concepts
>>>>> over and over.
>>>>>
>>>>> Let's start with branches.
>>>>>
>>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>>
>>>>> We currently have an AOO415 branch at
>>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>
>>>>> AOO415 branch will result in a release ONLY if we have some
>> important
>>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>>> even small enhancements, are added to it. No commits to AOO415
>> happen
>>>>> without appropriate mailing list discussions (dev or security,
>>>>> depending on cases).
>>>>>
>>>>> Trunk is where all development happens. It will be branched for a
>> new
>>>>> release (like, an AOO420 branch - name still provisional) when the
>>>>> code is mature: beta or even RC. Until then, we simply keep working
>>
>>>>> on trunk as we are doing now.
>>>>>
>>>>> In case we need to commit to a branch, any changes are still
>>>>> committed to trunk first and then merged to branches using SVN
>> merge
>>>>> in all situations when this is possible (i.e., when there are no
>>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear,
>> so
>>>>> we'll have to make sure that trunk contains all fixes done there
>> (or
>>>>> equivalent in case of conflicts) and, done that, we commit to
>> AOO415
>>>>> only if:
>>>>> 1. The fix is important and agreed upon on the relevant list
>>>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>>>
>>>>> 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 never result in a release.
>>>>>
>>>>> Regards,
>>>>> Andrea.
>>>>
>>>> Would it be more clear to just remove the AOO415 branch and only
>>>> re-instate it if needed (hopefully not). I don't see anything in
>>>> AOO415 that wasn't included in AOO414.
>>>>
>>>
>>> The decision to keep the 4.1.5 branch around came out of a discussion
>> on
>>> the security mailing list. The potential problem is that someday we
>> may
>>> be faced with a bug for which we need to get a fix out into the field
>> as
>>> soon as possible.
>>>
>>> Because of the sheer size of AOO, it takes time to get set up for a
>>> release. The idea is to do as much as we can to prepare without
>>> committing to a release. I have a check-out of AOO415 built. As the
>>> version number changes get incorporated I'll update and rebuild. Not
>>> having to wait for the branch to be prepared, check it out, and do a
>>> full build reduces by about a day the time it would take from knowing
>> a
>>> fix to having it built, tested, and checked in.
>>>
>>> I would like to make this an on-going policy. As soon as we ship
>> 4.2.0,
>>> we remove the AOO415 branch but create AOO421, identical except for
>>> version numbers to AOO420, ready in case of an emergency fix.
>>
>> +1
>> This is an good and cheap idea to speed things up.
>>
>> Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Peter kovacs <pe...@apache.org>.
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 contain the latest release candidate that gets prepared. It bases of from dev and propagates to release.
Hotfix is the one that bases on release and propagates back to release branch.
With this schema you have an abstract way in doing the same thing without the limitation of naming.
We could even post vote result into comments. When propagate version to release. Also we can decide on release name at the latest possible moment.
It would be less confusing especially if we rename a release. (4.2.0 is not final decided. But we may now have branch. Or we wait until we have decided but that would delay the result until we are done with the naming.)
Am 25. Oktober 2017 19:44:39 MESZ schrieb Marcus <ma...@wtnet.de>:
>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 or lazy consensus, and then we may want to
>reuse
>>>> this text in wiki or blog posts to avoid repeating the same
>concepts
>>>> over and over.
>>>>
>>>> Let's start with branches.
>>>>
>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>
>>>> We currently have an AOO415 branch at
>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>
>>>> AOO415 branch will result in a release ONLY if we have some
>important
>>>> bug fixes to release and trunk is not ready yet. No new features,
>>>> even small enhancements, are added to it. No commits to AOO415
>happen
>>>> without appropriate mailing list discussions (dev or security,
>>>> depending on cases).
>>>>
>>>> Trunk is where all development happens. It will be branched for a
>new
>>>> release (like, an AOO420 branch - name still provisional) when the
>>>> code is mature: beta or even RC. Until then, we simply keep working
>
>>>> on trunk as we are doing now.
>>>>
>>>> In case we need to commit to a branch, any changes are still
>>>> committed to trunk first and then merged to branches using SVN
>merge
>>>> in all situations when this is possible (i.e., when there are no
>>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear,
>so
>>>> we'll have to make sure that trunk contains all fixes done there
>(or
>>>> equivalent in case of conflicts) and, done that, we commit to
>AOO415
>>>> only if:
>>>> 1. The fix is important and agreed upon on the relevant list
>>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>>
>>>> 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 never result in a release.
>>>>
>>>> Regards,
>>>> Andrea.
>>>
>>> Would it be more clear to just remove the AOO415 branch and only
>>> re-instate it if needed (hopefully not). I don't see anything in
>>> AOO415 that wasn't included in AOO414.
>>>
>>
>> The decision to keep the 4.1.5 branch around came out of a discussion
>on
>> the security mailing list. The potential problem is that someday we
>may
>> be faced with a bug for which we need to get a fix out into the field
>as
>> soon as possible.
>>
>> Because of the sheer size of AOO, it takes time to get set up for a
>> release. The idea is to do as much as we can to prepare without
>> committing to a release. I have a check-out of AOO415 built. As the
>> version number changes get incorporated I'll update and rebuild. Not
>> having to wait for the branch to be prepared, check it out, and do a
>> full build reduces by about a day the time it would take from knowing
>a
>> fix to having it built, tested, and checked in.
>>
>> I would like to make this an on-going policy. As soon as we ship
>4.2.0,
>> we remove the AOO415 branch but create AOO421, identical except for
>> version numbers to AOO420, ready in case of an emergency fix.
>
>+1
>This is an good and cheap idea to speed things up.
>
>Marcus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Matthias Seidel <ma...@hamburg.de>.
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 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 repeating the same
>>>> concepts over and over.
>>>>
>>>> Let's start with branches.
>>>>
>>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>>
>>>> We currently have an AOO415 branch at
>>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>>> AOO415 branch will result in a release ONLY if we have some
>>>> important bug fixes to release and trunk is not ready yet. No new
>>>> features, even small enhancements, are added to it. No commits to
>>>> AOO415 happen without appropriate mailing list discussions (dev or
>>>> security, depending on cases).
>>>>
>>>> Trunk is where all development happens. It will be branched for a
>>>> new release (like, an AOO420 branch - name still provisional) when
>>>> the code is mature: beta or even RC. Until then, we simply keep
>>>> working on trunk as we are doing now.
>>>>
>>>> In case we need to commit to a branch, any changes are still
>>>> committed to trunk first and then merged to branches using SVN
>>>> merge in all situations when this is possible (i.e., when there are
>>>> no merge conflicts). The mergeinfo for AOO414 and AOO415 isn't
>>>> clear, so we'll have to make sure that trunk contains all fixes
>>>> done there (or equivalent in case of conflicts) and, done that, we
>>>> commit to AOO415 only if:
>>>> 1. The fix is important and agreed upon on the relevant list
>>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>>
>>>> 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 never result in a release.
>>>>
>>>> Regards,
>>>> Andrea.
>>>
>>> Would it be more clear to just remove the AOO415 branch and only
>>> re-instate it if needed (hopefully not). I don't see anything in
>>> AOO415 that wasn't included in AOO414.
>>>
>>
>> The decision to keep the 4.1.5 branch around came out of a discussion on
>> the security mailing list. The potential problem is that someday we may
>> be faced with a bug for which we need to get a fix out into the field as
>> soon as possible.
>>
>> Because of the sheer size of AOO, it takes time to get set up for a
>> release. The idea is to do as much as we can to prepare without
>> committing to a release. I have a check-out of AOO415 built. As the
>> version number changes get incorporated I'll update and rebuild. Not
>> having to wait for the branch to be prepared, check it out, and do a
>> full build reduces by about a day the time it would take from knowing a
>> fix to having it built, tested, and checked in.
>>
>> I would like to make this an on-going policy. As soon as we ship 4.2.0,
>> we remove the AOO415 branch but create AOO421, identical except for
>> version numbers to AOO420, ready in case of an emergency fix.
>
> +1
> This is an good and cheap idea to speed things up.
>
> Marcus
To be prepared we should now complete the missing steps to make the 415
branch ready.
I am not sure if only the release manager is allowed to do it?
Matthias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [PROPOSAL] Managing branches for future releases
Posted by Marcus <ma...@wtnet.de>.
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 or lazy consensus, and then we may want to reuse
>>> this text in wiki or blog posts to avoid repeating the same concepts
>>> over and over.
>>>
>>> Let's start with branches.
>>>
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>
>>> We currently have an AOO415 branch at
>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>> AOO415 branch will result in a release ONLY if we have some important
>>> bug fixes to release and trunk is not ready yet. No new features,
>>> even small enhancements, are added to it. No commits to AOO415 happen
>>> without appropriate mailing list discussions (dev or security,
>>> depending on cases).
>>>
>>> Trunk is where all development happens. It will be branched for a new
>>> release (like, an AOO420 branch - name still provisional) when the
>>> code is mature: beta or even RC. Until then, we simply keep working
>>> on trunk as we are doing now.
>>>
>>> In case we need to commit to a branch, any changes are still
>>> committed to trunk first and then merged to branches using SVN merge
>>> in all situations when this is possible (i.e., when there are no
>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so
>>> we'll have to make sure that trunk contains all fixes done there (or
>>> equivalent in case of conflicts) and, done that, we commit to AOO415
>>> only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>
>>> 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 never result in a release.
>>>
>>> Regards,
>>> Andrea.
>>
>> Would it be more clear to just remove the AOO415 branch and only
>> re-instate it if needed (hopefully not). I don't see anything in
>> AOO415 that wasn't included in AOO414.
>>
>
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
>
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
>
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.
+1
This is an good and cheap idea to speed things up.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1. Having a branch ready to roll is cheap insurance.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Mechtilde <oo...@mechtilde.de>.
+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 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 repeating the same concepts
>>> over and over.
>>>
>>> Let's start with branches.
>>>
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>
>>> We currently have an AOO415 branch at
>>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this
>>> branch is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The
>>> AOO415 branch will result in a release ONLY if we have some important
>>> bug fixes to release and trunk is not ready yet. No new features,
>>> even small enhancements, are added to it. No commits to AOO415 happen
>>> without appropriate mailing list discussions (dev or security,
>>> depending on cases).
>>>
>>> Trunk is where all development happens. It will be branched for a new
>>> release (like, an AOO420 branch - name still provisional) when the
>>> code is mature: beta or even RC. Until then, we simply keep working
>>> on trunk as we are doing now.
>>>
>>> In case we need to commit to a branch, any changes are still
>>> committed to trunk first and then merged to branches using SVN merge
>>> in all situations when this is possible (i.e., when there are no
>>> merge conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so
>>> we'll have to make sure that trunk contains all fixes done there (or
>>> equivalent in case of conflicts) and, done that, we commit to AOO415
>>> only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>
>>> 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 never result in a release.
>>>
>>> Regards,
>>> Andrea.
>>
>> Would it be more clear to just remove the AOO415 branch and only
>> re-instate it if needed (hopefully not). I don't see anything in
>> AOO415 that wasn't included in AOO414.
>>
>
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
>
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
>
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
Mechtilde Stehmann
## Apache OpenOffice.org
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## Loook, calender-exchange-provider, libreoffice-canzeley-client
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F
Re: [PROPOSAL] Managing branches for future releases
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Oct 24, 2017 at 4:00 PM, Patricia Shanahan <pa...@acm.org> 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 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 repeating the same concepts over and over.
>>>
>>> Let's start with branches.
>>>
>>> We all wish 4.1.4 to be the last 4.1.x release.
>>>
>>> We currently have an AOO415 branch at http://svn.apache.org/viewvc/o
>>> penoffice/branches/AOO415/ ; this branch is a copy of AOO414 (that
>>> resulted in OpenOffice 4.1.4). The AOO415 branch will result in a release
>>> ONLY if we have some important bug fixes to release and trunk is not ready
>>> yet. No new features, even small enhancements, are added to it. No commits
>>> to AOO415 happen without appropriate mailing list discussions (dev or
>>> security, depending on cases).
>>>
>>> Trunk is where all development happens. It will be branched for a new
>>> release (like, an AOO420 branch - name still provisional) when the code is
>>> mature: beta or even RC. Until then, we simply keep working on trunk as we
>>> are doing now.
>>>
>>> In case we need to commit to a branch, any changes are still committed
>>> to trunk first and then merged to branches using SVN merge in all
>>> situations when this is possible (i.e., when there are no merge conflicts).
>>> The mergeinfo for AOO414 and AOO415 isn't clear, so we'll have to make sure
>>> that trunk contains all fixes done there (or equivalent in case of
>>> conflicts) and, done that, we commit to AOO415 only if:
>>> 1. The fix is important and agreed upon on the relevant list
>>> 2. The commit is done with "svn merge" starting from a trunk commit
>>>
>>> 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 never result in a release.
>>>
>>> Regards,
>>> Andrea.
>>>
>>
>> Would it be more clear to just remove the AOO415 branch and only
>> re-instate it if needed (hopefully not). I don't see anything in AOO415
>> that wasn't included in AOO414.
>>
>>
> The decision to keep the 4.1.5 branch around came out of a discussion on
> the security mailing list. The potential problem is that someday we may
> be faced with a bug for which we need to get a fix out into the field as
> soon as possible.
>
> Because of the sheer size of AOO, it takes time to get set up for a
> release. The idea is to do as much as we can to prepare without
> committing to a release. I have a check-out of AOO415 built. As the
> version number changes get incorporated I'll update and rebuild. Not
> having to wait for the branch to be prepared, check it out, and do a
> full build reduces by about a day the time it would take from knowing a
> fix to having it built, tested, and checked in.
>
> I would like to make this an on-going policy. As soon as we ship 4.2.0,
> we remove the AOO415 branch but create AOO421, identical except for
> version numbers to AOO420, ready in case of an emergency fix.
>
Thanks for this explanation. It makes good sense.
--
----------------------------------------------------------------------
MzK
"Only the truth will save you now."
-- Ensei Tankado, "Digital Fortress"
Re: [PROPOSAL] Managing branches for future releases
Posted by Patricia Shanahan <pa...@acm.org>.
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 this text
>> in wiki or blog posts to avoid repeating the same concepts over and over.
>>
>> Let's start with branches.
>>
>> We all wish 4.1.4 to be the last 4.1.x release.
>>
>> We currently have an AOO415 branch at
>> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
>> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
>> branch will result in a release ONLY if we have some important bug
>> fixes to release and trunk is not ready yet. No new features, even
>> small enhancements, are added to it. No commits to AOO415 happen
>> without appropriate mailing list discussions (dev or security,
>> depending on cases).
>>
>> Trunk is where all development happens. It will be branched for a new
>> release (like, an AOO420 branch - name still provisional) when the
>> code is mature: beta or even RC. Until then, we simply keep working on
>> trunk as we are doing now.
>>
>> In case we need to commit to a branch, any changes are still committed
>> to trunk first and then merged to branches using SVN merge in all
>> situations when this is possible (i.e., when there are no merge
>> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
>> have to make sure that trunk contains all fixes done there (or
>> equivalent in case of conflicts) and, done that, we commit to AOO415
>> only if:
>> 1. The fix is important and agreed upon on the relevant list
>> 2. The commit is done with "svn merge" starting from a trunk commit
>>
>> 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 never result in a release.
>>
>> Regards,
>> Andrea.
>
> Would it be more clear to just remove the AOO415 branch and only
> re-instate it if needed (hopefully not). I don't see anything in AOO415
> that wasn't included in AOO414.
>
The decision to keep the 4.1.5 branch around came out of a discussion on
the security mailing list. The potential problem is that someday we may
be faced with a bug for which we need to get a fix out into the field as
soon as possible.
Because of the sheer size of AOO, it takes time to get set up for a
release. The idea is to do as much as we can to prepare without
committing to a release. I have a check-out of AOO415 built. As the
version number changes get incorporated I'll update and rebuild. Not
having to wait for the branch to be prepared, check it out, and do a
full build reduces by about a day the time it would take from knowing a
fix to having it built, tested, and checked in.
I would like to make this an on-going policy. As soon as we ship 4.2.0,
we remove the AOO415 branch but create AOO421, identical except for
version numbers to AOO420, ready in case of an emergency fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Andrea Pescetti <pe...@apache.org>.
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 have the code ready for it at any moment, so that
we can really just focus on committing the actual fixes and building in
case.
> I don't see anything in AOO415 that wasn't included in AOO414.
Of course. The two are identical right now. The only fixes that will go
into the branch are for the release number updates. Anything else will
go there only after it is fixed in trunk and only after approval on the
relevant list.
And if trunk is fast enough, we will simply remove the AOO415 branch
without releasing anything from it.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PROPOSAL] Managing branches for future releases
Posted by Kay Schenk <ka...@gmail.com>.
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 repeating the same concepts over and over.
>
> Let's start with branches.
>
> We all wish 4.1.4 to be the last 4.1.x release.
>
> We currently have an AOO415 branch at
> http://svn.apache.org/viewvc/openoffice/branches/AOO415/ ; this branch
> is a copy of AOO414 (that resulted in OpenOffice 4.1.4). The AOO415
> branch will result in a release ONLY if we have some important bug fixes
> to release and trunk is not ready yet. No new features, even small
> enhancements, are added to it. No commits to AOO415 happen without
> appropriate mailing list discussions (dev or security, depending on cases).
>
> Trunk is where all development happens. It will be branched for a new
> release (like, an AOO420 branch - name still provisional) when the code
> is mature: beta or even RC. Until then, we simply keep working on trunk
> as we are doing now.
>
> In case we need to commit to a branch, any changes are still committed
> to trunk first and then merged to branches using SVN merge in all
> situations when this is possible (i.e., when there are no merge
> conflicts). The mergeinfo for AOO414 and AOO415 isn't clear, so we'll
> have to make sure that trunk contains all fixes done there (or
> equivalent in case of conflicts) and, done that, we commit to AOO415
> only if:
> 1. The fix is important and agreed upon on the relevant list
> 2. The commit is done with "svn merge" starting from a trunk commit
>
> 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 never result in a release.
>
> Regards,
> Andrea.
Would it be more clear to just remove the AOO415 branch and only
re-instate it if needed (hopefully not). I don't see anything in AOO415
that wasn't included in AOO414.
--
------------------------------------------
MzK
"Only the truth will save you now."
-- Ensei Tankado, "Digital Fortress"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org