Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
We create the 1.5.x branch *now*, but don't release yet.
That depends on how Juergen will manage the "stable" series. I
personally would like that we continue trunk development on the 1.5
series instead of opening a new 1.5.x branch. I would like to propose
that we alternate between bug-fixing release and feature release.
I don't see the advantage of this. I'd rather do a 1.5.x branch and let people
do some more adventourous development (or new features) in trunk.
I am thinking of GUI development. Dialogs, context menu, etc...
If XML is
too risky, that could be developped further in Lars' XML branch until people
think it's ready for merging (as we did with unicode).
I think this does not work: Lars' unicode branch was developed only by
him. Only when it was merged in trunk others stepped in to finish the
work. The main problem is that 3 branches is too much to keep track and
that is why I am proposing that we only keep two main branches.
Something like this:
1.5.0: released at T0
1.5.1: T1=T0+1month, bug fixes only, small patches (<100 lines?)
Yes.
1.5.2: T2=T1+2/3month, feature release, big patch and cleanup allowed
Probably yes. Depends on what remains from the 1.5.1 bugfixing and what bug
reports we have. Main focus is _always_ on stability. New features should
therefore be very well tested and straightforward.
Sure, only incremental feature and cleanup should go in. That is why the
time window for introducing a feature should be short: maybe 15 days
after the last buxfix release.
1.5.3: T3=T2+1month, bug fixes only, small patches (<100 lines?)
etc.
That means that the even releases are supposed to be less stable than the odd
ones? I don't like this.
Hopefully not but it could happen with new features yes. In any case a
bug-fix release will happen just afterwards.
Of course, no format change will be allowed in the 1.5.x series.
Of course not.
During this time the XML branch continues to be developed and, when more
or less finished, it becomes the new development branch (or we merge it
to trunk).
My rationale is that we have to be realistic with the XML change: not
everybody will contribute. If we switch trunk to XML immediately non
interested developers will get stalled because of the transition.
Therefore the stabilizing in the xml branch. And after the merge, all
developpers are simply forced to deal (and help) with XML. I think that
worked out quite well in the unicode case.
Are you kidding? The unicode transition was pretty painful; a big part
of the work was done after the branch was merged. During this time only
three developers were really active.
The added benefit will be that a lot of long standing bug can and will
be fixed in the "stable" branch.
That should be done nevertheless.
This will not be done if we have to track three branches at the same time.
Abdel.
