Florian Klaempfl ha scritto:
Vincent Snijders schrieb:
4) With painful "diff's", or with information from developers,
determine the patches to be applied, for bugs fixed since march 27
(?), and try to see if what comes out is a working version, or just a
pitiful mess. This phase can be useful to establish in practice the
policy guidelines. I'm in favor of a rather conservative approach,
because the goal is to provide a stable version, not all fancy nice
new features, but what this means in practice must be verified.
Logs can be helpful:
http://www.freepascal.org/cgi-bin/viewcvs.cgi/lazarus-all.log?root=logs&view=markup
Also consider looking into svnmerge as described here:
http://wiki.lazarus.freepascal.org/SVN_Migration#Merging
Hmm, while you are at the wiki, maybe put some documentation about the
process there too.
svnmerge works very well, we use it to maintain the fpc fixes branches.
After you branched (from a certain version of trunk), you can easily
merge revisions to fixes or display unmerged revisions.
BTW: I guess the best solution is to introduce a fourth version number
like 0.9.22.1 to mark the stable branch till 1.0.x is out and you can
follow the fpc version numbering scheme.
O.K. Thanks. First of all I'll manage to set up a local repository,
create a branch named fixes_0_9_22 (good suggestion, that way we're also
consistent with fpc conventions), and play with svnmerge to create a few
versions 0.9.22.x picking up fixes that I deem useful, and see that one
can still open the IDE and make a form with a button without major
crashes! :-)
Then I may submit a commented log (this goes in, this we let out, this I
don't know) to decide what should go in the "real" fixes branch.
Giuliano
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
