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 <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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
