Am 26.10.2017 um 07:03 schrieb Peter kovacs:
Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <marcus.m...@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
<marcus.m...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
