Am 25. Oktober 2017 21:25:42 MESZ schrieb Marcus <marcus.m...@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 ><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
