In the future, when doing these pre-release tests, would it make
sense to adjust the Release tags in the RPM packaging sections to
reflect an ordered but prerelease nature of the builds?
For instance, the first patch set built "3.0.23c-1" rpms. The
second patch set also builds "3.0.23c-1" rpms. These aren't seen as
updates, and would have to be force-installed.
I manually adjusted the Release tag in the SPEC file from "1" to "2",
to build "3.0.23c-2" rpms, which will then update cleanly. When the
release tarball comes out, you'll probably still have the RPM Release
tags still at "1", and then I'll have to adjust the SPEC's Release: tag to "3".
May I suggest adjusting the Release tags in the SPEC files upward for
each successive patch/release? One could (I think) even adopt a
strategy of using Release values of "0.1", "0.2", etc. for prerelease
patches/tests/etc., and then jumping to "1" for the actual "release" versions.
At 01:38 PM 8/30/2006, Gerald (Jerry) Carter wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I've uploaded the *final* 3.0.23c roll up patch to
I've already cut the 3.0.23c tarballs so unless there is
a major problem, this will be the final change set.
Please report *any* bugs that you find. I'd like to wrap
this one up and do the public 3.0.23c release on Friday.
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
To unsubscribe from this list go to the following URL and read the
Don Meyer <dlmeyer@xxxxxxxx>
Network Manager, ACES Academic Computing Facility
Technical System Manager, ACES TeleNet System
UIUC College of ACES, Information Technology and Communication Services
"They that can give up essential liberty to obtain a little
deserve neither liberty or safety." -- Benjamin Franklin, 1759