On 28 Nov 2012, at 16:02, luiz americo pereira camara wrote:
2012/11/28 Jonas Maebe <jonas.ma...@elis.ugent.be>:
Personally, I think a release candidate is too late. A release
candidate
freezes all interfaces (even a beta release does so already,
normally).
Generally the only fixes still performed afterwards are for blocking
crashers/failures, major security holes or build issues.
Yes. This proposed change breaks the concept of release candidate.
My point here is this is the first release open for wide test with
this feature.
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.
Given that better discuss / test / change such important change
earlier than later, nothing stops to treat this release as a beta (or
whatever name is appropriate) even if was formally released as a RC.
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).
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.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
