Hi - I’ll bite on a discussion. Overall I think that we are mixing two different purposes.
(1) Keeping track of what is or may be released. This is what the current scheme does well when we are on a branch and not so well when we are on trunk. (2) Managing the lifecycle of a particular release. You propose a fairly common step model. I think that we go to a release branch sometime in your TEST. We have a very complex build process where a little change on Windows might make the Unix or Mac build unstable. I would propose that we operate more like so. We have two types of branches. (A) Release branches as we do now. These have Test, Release and Maintenance phases. In this case all of our 4.1.X branches including 4.1.5 are in maintenance. (B) Feature branches would be new for AOO. In these branches we co-operate between DEV and Test phases. We work out build issues on each platform for the feature in isolation. Community testers can be given test builds, etc. Branches are merged to Trunk or a Release at certain times in the lifecycle. When a merge is done a phase of TEST is required on the result. Example. (1) Create an SDBC feature branch from trunk. (2) Create a 4.2.0 release branch from trunk. (3) Create an update Java feature branch from trunk. (4) Develop and test the Java update. (5) Merge the Java feature branch to SDBC feature branch. (6) Develop and test the SDBC feature branch. (7) Merge the SDBC feature branch to trunk and TEST. (8) Merge trunk to 4.2.0 release branch. (9) Test the 4.2.0 release branch. (10) Release 4.2.0. Other feature branches could be: - Sign the Mac Application with an Apple Developer key. - Bullet proof Windows Installer to reject spammers. Regards, Dave > On Oct 27, 2017, at 2:28 PM, Peter Kovacs <leg...@posteo.de> wrote: > > Disclaimer: > I do not claime that one solution is the ultimate solution over the > other. > > But I would like to explain my approach as long as it takes until > everybody says he understood what I am suggesting. Nothing more nothing > less. No religeous war is intended or whished from my side. > end disclaimer. > > Am Donnerstag, den 26.10.2017, 20:27 +0200 schrieb Marcus: >>> 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. > It is a life cyle model. You do not need to know a release number. > A release number does tell nothing. > A life Cycle state tells you exactly which state the Product is in. > > DEV: It is under development. The code can have serious bugs, break. > But can also have the newst feature that may only partial implemented. > In general the code is good enough that it compiles on the dev > machines. > > TEST: Often revered to unstable. > The Code is in a feature freeze. It recieves bugfixes, that stabilize > the Code until it reaches the maturity that we expect from it. TEST > unlike DEV takes picks only new features up at a certain time. > Usually after the Code has reached a maturity state. > > > Release: often reverred to Stable. > The branch that only contains best possible code, to have transperency. > It also is the source to give people a clear state what is changing > from one change to the next. > > hotfix, means maintenance: > This should be an exception. When we feel we need to fix something on > release level, because we missed a bug in the maturity phase. > > It is a complete different development model. We can use Release > numbers to name a specific cycle. But we control the code not by that > number. We could give it also a Name like "Eternia Version" Would have > the same meaning. > > Let me draw a picture, a fantasy example for illustration: > Time --------> > by live cycle: > 4.1.4 4.1.5 > hotfix -x--x---+ +--x--x---x+ 4.2.0 > Release --------V------------+----------V---------------A------------- > born:4.2.0 every x here a bugfix born:5.0.0 > > Test -----------A------x---x-----x--x--x---x----x--x-+-A---x--x---x- > Dev ----x----x-+-x--------x------------x---------x--V-+------------ > PSQL1&2 OOXML Googlestuff Root-lib | fix integration > video feature > > by release Number: > PSQL1&2 OOXML Googlestuff Root-lib Sience-interface > trunc -x--x----x-+-x----x---x-----x--x--xx--x----x-x----+-+--x--x---x- > 4.1.4 -x--x---+ > 4.1.5 +--x--x---x+ > 4.2.0 +-x----x---x-----x--x--x---x----x--x-+ > 5.0.0 +---x--x---x- > > The above example does not break any history. You have a clear state, > on the advancement of the code. > You can compare at any given time the code (I.E. using fisheye). And > you can archieve by time. > In the above model we restrict sharing of changes to certain moments of > time. So the state is always defined. > > The lower example due the nature of the approach you have in each > branch a single "fork". The advantage is that you can maintain each > Version from the other. You can also reintegrate a external Fork based > on someotherworks with ease. > But comparing branches is not guaranteed, since they are disconected to > each other. Both could be potential be maintained. > Plus at any moment you can have bugs or features introduce to your > branch, as you like, but probably it is not intended. > Archiving is done by time on trunc, and by release on branche. Getting > time and branch together again might be difficult. Maybe we could > archieve both if we go by time and branch so only complete branches are > saved. > > Of course a lot of things assumed here is pure agreement and disciplin. > However I do not see any benefit to us in maintaining each version as > an own branch, since we do not want to maintain the branches. > As you see in the Picture. > > It is the methology of thinging. In released based production it is of > course dreadfull to mix branches, because you do your controling by > release numbering. > In my suggested model you do not controlling by a release number but by > state of the code. by which we push our core value "stability over > Feature" into our steering centre. > > Also we would like to have almost none hotfixes. Maybe they can be done > as branches seperatly since there it can realy get confusing which > state a hotfix branch is in. And we need it only for ensuring that fix > does not break anything else. So normaly hoitfix brnches have a short > live period. > > Also some thoughts about Release number: > The methology of Agile programming is often reduced to release often. > Which may translate to the idea that release number needs to rattle up. > (Firefox anyone?) > I think it is a stupid Idea, and does not work. It comes from an aera > when Versionening systems were none existand. > Does anyone use time dates to version his documents on disk? > It is the same system just less abstract. > > I think we need to pull the community together. If there are companies > out there using open office, we must convince them to integrate our > process of updating in their workstream. > Only then we will get business interest, and an effective drive on a > clear open source model. > > Relase Model can give a business entity to skipp specifying their > requirements on us and take the lazy method in trying to stick to the > Version they have. A "rolling release" discourages this. > > I also would like to add as an argument against rolling modell, that > our build environment and our publish procedures are closely tied to > the release model. > To switch the modell is probably not an easy thing to do. > Things I have noted from the discussion: > - Automated builds is super important I think in a rolling modell. > - Version number is tied in multiple places, which is awkward at best. > - Dictionaries are not covered in the modell. And I am not sure how > they move with that, because they have their own cycle. > If we could make code more intependant from the dictionaries, we could > let them swing independently from each other, which would be super > cool. but that would mean that an dictionary update is done compile > free. > - We must get better at updateing an installed version. I think the > need to reset or delete the profile is in general not good. > > So I hope this rather lengthy email is explaining all stuff. > I hope I did not scare anyone with this lengthy explanation now. > > All the best > Peter > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org >
signature.asc
Description: Message signed with OpenPGP
