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