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 <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
