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
