Martin Sebor wrote:
Justin Erenkrantz wrote:
--On January 18, 2006 5:30:04 PM -0700 Martin Sebor
<[EMAIL PROTECTED]> wrote:
I don't think of the name of a file mentioned in emails as a release,
least of all when it refers to a transient file in someone's home
directory. Similarly, I don't consider an SVN branch to be an actual
release, even if its contents were identical to it. With this mindset
I can only see one potential effect of skipping versions on users --
that of confusion.
One of the problems in working in open-source projects is that
everyone can see the release immediately. Therefore, we don't have
the ability to 'take' a release back - once you tag it or announce it
in any public forum, it's gone. By enforcing a 'cheap' version number
policy, we remove any confusion: were they using the '1.2.3' release
from Jan 10 or was that the '1.2.3' release from Jan 15? Instead, we
make it crystal clear what the release was by only allowing that
version to be used once. -- justin
I understand the motivation behind the policy and fully support
the goal of preventing the problem it is designed to address.
However, I believe that the issue can be just as effectively
dealt with by implementing the -rcN (or similar) suffix policy
that Bill mentioned in his first post, with the additional
(and IMO essential) advantage of preserving the well-established
meaning of the version number grounded in precisely defined
technical criteria.
I agree with Martin -if- the SVN tag is also designated tags/1.2.3-rcN
until it's voted in, and then copied or renamed to tags/1.2.3 upon release.
