On Jan 12, 2012, at 11:58 AM, Scot Kronenfeld wrote: > On Mon, Jan 9, 2012 at 4:58 PM, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote: >> >> On Jan 9, 2012, at 4:53 PM, Scot Kronenfeld wrote: >> >>> Brian, >>> We've tossed out the idea of including the git hash in the file names, but: >>> a) it's not monotonically increasing, so it can't be used as the >>> version. You worked around that by also including the build number. >>> b) we worried it is too long - at least without trimming. I assume >>> you don't want to see an RPM named: >>> condor-7.7.5-0.b24406.6c8f0737e62a145b3ed074d48ace82996beecaa0.rhel5.x86_64.rpm >>> >> >> Oh yeah, you definitely need the trimmed hash. >> >>> I'm ok with the development versions having a trimmed hash if you >>> would find it useful. >>> >> >> I think having build + hash will be very convenient for pre-release versions - it'll be monotonically increasing (making NMI happy) and refer to a specific place in the source code (making devs happy). >> >> Still - for (non-daily) tagged builds, we should drop any extensions and just do "condor-7.7.5". Adding the build number in release would just be confusing for external folks. > > This would require a process change on our part to issue a final > condor-.7.7.5 RPM (with no build tag, etc) in order to not have the > same problems that is driving this change. We'll discuss it more in > the FW meeting on Monday. > I'm not sure what the problems are, but I think it'd be pretty distracting to the user to add in a piece of meaningless information (in the user's perspective). Why can't you have: condor-<version>-0.b.<build #> for all the pre-releases, then condor-<version>-1 for the final release (and you can detect the final tag by seeing if the git hash is equal to a tag)? You still have a monotonically increasing packages up to the release. Brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature