<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 28 Nov 2012, at 16:02, luiz americo pereira camara wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">2012/11/28 Jonas Maebe <<a href="mailto:jonas.maebe@elis.ugent.be">jonas.maebe@elis.ugent.be</a>>:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">Personally, I think a release candidate is too late. A release candidate<br></blockquote><blockquote type="cite">freezes all interfaces (even a beta release does so already, normally).<br></blockquote><blockquote type="cite">Generally the only fixes still performed afterwards are for blocking<br></blockquote><blockquote type="cite">crashers/failures, major security holes or build issues.<br></blockquote><br>Yes. This proposed change breaks the concept of release candidate.<br><br>My point here is this is the first release open for wide test with this feature.<br></span></span></blockquote><div><br></div><div>The first release of new features in FPC always happens via the svn repository. That is the moment to test them and give feedback. Once they end up in a release, they are final. Daily snapshots of FPC that can be used for testing are available from the Lazarus project.</div><br><blockquote type="cite"><span class="Apple-style-span" style="font-family: monospace; ">Given that better discuss / test / change such important change</span></blockquote><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">earlier than later, nothing stops to treat this release as a beta (or<br>whatever name is appropriate) even if was formally released as a RC.<br></span></span></blockquote></div><br><div>The appropriate name would be "alpha". What stops treating the release candidate as an alpha and making invasive changes to it, is that this would significantly slow down the release process (every time we ship a release candidate, someone could pop and say "hey, please change this RC to an alpha version and add/change this -- this would also discourage people from testing the svn versions, since they'd assume they can always delay the release if there's something they don't like).</div><div><br></div><div>The only possible alternative in this case that I can see would be to remove the new feature altogether from the release (that's still a change, but one thta changes things back to the situation of the previous release and hence is known to be "stable"). However, from what I read from Michael's replies, that would not help since he does not seem to be inclined to change things.</div><div><br></div><div><br></div><div>Jonas</div></body></html>