hi there,
On 1/17/07, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
> Er, then the packages should be named 1.2.1. The problem with doing
> all of our laundry in public is that the public often download our
> unreleased packages even when we tell them not to. For that reason,
> most Apache projects increment the patch-level number each time a
> new package is produced (releases do not need to be sequential).
I agree that it's troublesome to have produced two sets of packages
both versioned as "1.2". My approach so far has been to use the -rcN
version suffix for candidate packages used for testing an upcoming
release, and I think that approach has worked quite well. However, in
order to have the official release vote happen on the actual physical
packages that get released, I've had to drop the -rcN suffix from the
last release candidate. So far it's worked fine, but now we had a last
minute blocker issue that caused the need to repackage the release.
Packaging the fixed release as 1.2.1 is a valid solution, and I'll
make it happen if that's the consensus. I personally find the
unsequential version numbering practice somewhat confusing and
adopting it would also require some changes also to our Jira usage.
It's however nothing we couldn't handle, so I have no strong
objections. That way the last part of the release number would be more
like a build sequence number than a planned version number.
so what would happen if you had to release a "real" patch to jackrabbit 1.2.1?
would it be versioned 1.2.1.1 then? or 1.2.2?
the usage of the 3rd version digit as a sort of rc counter sounds
rather confusing to me, too...
how about always suffixing release candidates that are voted on with
-rcN, and after acceptance releasing the same binaries again, this
time without suffixes? their md5 checksums would be identical, so
there should be no confusion as to which rc it is, and the release
would have the proper version.
/rofe
