<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
We can stick with the current release branch if that is indeed much easier.<br>
<br><br>I thought there was some agreement we shouldn't release LONGINT as it was.<br>I can undo the changes if we want.<br>It's not easy with cvs (not much is) but I can do it.<br>It's easy for me to diff the trees, just using windiff or diff (again, cvs<br>seems not to help).<br><br><br><br>Many/most/all of the fixes went first into head, so there's "nothing" to merge back,<br>but diff tells us better.<br><br><br>I'm still planning on setting up some more machines and can do FreeBSD4.<br>(I have PPC64_DARWIN and PPC32_OPENBSD about ready, but<br>I have to check if Modula-3 actually works on them first...)<br><br><br>Does anyone have the missing steps for the cvsup bug report, like the configuration file,<br>can show the callstacks, try it with user threads..etc..?<br><br><br> - Jay<br><br><br>> Date: Sun, 17 Jan 2010 12:38:16 +0100<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: [M3devel] Release Engineering: 5.8 --> 5.9? was: Re: release vs. head?<br>> <br>> Quoting Jay K <jay.krell@cornell.edu>:<br>> <br>> > Should we just make a new release branch?<br>> > Or I keep copying stuff over somewhat selectively?<br>> > We do want LONGCARD in the release, I assume.<br>> ><br>> > I'll diff the two trees again, see what varies.<br>> > Sometimes when I do that I find stuff to take.<br>> > And take the LONGCARD changes.<br>> <br>> From a release engineering point of view this is more or less<br>> a nightmare. We cannot make incompatible extensions to the feature<br>> set after the fourth release candidate.<br>> <br>> The only clean way I'd see to even get the LONGINT changes into the<br>> next release would be to start anew. Meaning declaring 5.8.4 as<br>> the latest release and develop 5.9 on the trunk. Of course we'd<br>> have to carefully merge back any fixes that might be missing on the<br>> trunk right now.<br>> <br>> That said, I have currently neither the time nor the energy to do all<br>> that cleanly. I didn't even get round to set up release builds<br>> on new.elego.de via Hudson in order to cover the FreeBSD4 target<br>> platform we recently lost in the release due to my home machine's<br>> complete crash in December. So the release engineering support is not<br>> in the best of states I must admit.<br>> <br>> I could live with declaring 5.8.RC4 as an intermediate release,<br>> but somebody really needs to do all the housekeeping of comparing<br>> and merging branches. And we shouldn't start a new release branch<br>> until things have settled down.<br>> <br>> Is anybody interested in taking over some of the release engineering<br>> tasks (including Hudson management and re-targeting to the new release)?<br>> <br>> Please keep in mind that we haven't managed to get out a stable release<br>> for several years now.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br> </body>
</html>