Hi, I'm for 1), too. If Brian's right and there was a decision on having the second digit as sign for stability, then I'd rather make it 4.0.1.
If the architecture change of trunk is big enough for getting a 4.1.X version, better move 4.0.X into a si-4.0 branch, and evolve it separately into 4.0.1/2/3... Whether rsync is called 2.6.X or 3.0.X, I'm optimistic that code is generally improving. If the new version does the job, why not? Can you change the release notes of the 4.0.0 version on the sourceforge page? If you can add a comment on the bug, you should leave the version there. But it has no value, actually, once you added the fixed version. You're not deleting the svn tags, so old versions are still available, even if you remove the buggy things from SF.net. Regards, Erich On Thursday 08 November 2007 00:25, Andrea Righi wrote: > Hi all, > > it seems that someone is agree with me and someone is not about the solution > to > add the pre-release of rsync (3.0.0pre4) into the stable branch of > SystemImager > and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for > development pre-releases). > > So, probably this is the first polling in these lists :-), don't know, but I > would really like to know opinion of the community about this issue. > > The fact is that the current stable release of SystemImager 4.0.0 is not > "stable" enough: there is a bug that occurs with rsync when it's built on a > machine with a kernel >= 2.6.22 (that's actually my build server) and the > installing client uses a kernel < 2.6.22: > > See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for > details, > many thanks to Rochus Schmid for reporting this bug. > > The proposed solutions for now are: > > 1) use the pre-release of rsync that seems to fix the problem and tag > SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I > would just proceed like the kernel guys do if there's a bug in the kernel > (just > leave all the previous released kernels "forzen" and available for download in > any case, and always release new versions in case of errors/bugs) > > 2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the > users), rebuild all the packages in a build server with a kernel < 2.6.22 and > then release the new packages using the same version number: 4.0.0 > > 3) rebuild the packages in a build server with a kernel < 2.6.22 and changing > the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net > > 4) other ideas are welcome... > > I vote for 1). > > -Andrea > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > sisuite-devel mailing list > sisuite-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sisuite-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sisuite-devel mailing list sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
