On Friday, 31 May 2013 at 14:08:17 UTC, Leandro Lucarella wrote:
About this, AFAIK 2.063.1 is really what's in the release, but
the
binary version number (and the zip name) have only 2.063. I
think that
should be fixed and the real version number should be present
in both
downloadables and binary. Also a micro changelog should be
provided,
only with the regressions that were fixed.
Of course, that absolutely makes sense and should be implemented
by next release if possible.
And I don't mean to minimize the incredible breakthrough
concerning the
release process in this cycle, just pointing out places were we
can
still do better :)
Agreed. Looking back just a couple of releases ago, the situation
has improved considerably, but as always there's a lot more
improvements that can and should be done.
As for the comment that RC's will be treated as stable releases,
that's hard to swallow, esp when you consider what's going on
now. The current release is worse than a RC because it's not
labeled for what it is, people will think it's stable when in
fact it's not. I think that it is far more professional and
responsible to explicitly state that the version on the download
page is a release candidate rather than not saying anything at
all. People will get the wrong impression and think that it is a
well tested and honed stable release.
To reduce potential confusion, we can place RC's in a separate
download page.
Finally the RC can be a reasonably well tested version that is
near completion to minimize the amount of re-work and bug
potential. Even if it is misused by people who should know
better, it'll still perform reasonably well, and the rest of us
tinkerers will greatly benefit from having it.
Finally, making RC's available to the public will greatly help
increase the quality of the final product and increase the
confidence in it for production use.
It'll be a win-win for everyone, no question in my mind.
--rt
