Re: [Condor-devel] Proposed changes to tarball and native package names

[Scot Kronenfeld <kronenfe@xxxxxxxxxxx>]

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

I'm ok with the development versions having a trimmed hash if you
would find it useful.

-scot

On Fri, Jan 6, 2012 at 4:50 PM, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote:
> Hi Scot,
>
> Why don't we do something more standard for pre-releases:
>
> condor-<X.Y.Z>-0.<release>.git.<git hash>
>
> where <release> is a monotonically increasing number (may be build number, I suppose).
>
> However, I'd strongly prefer this not be done for the final build, just to not clutter up the package number.
>
> Brian
>
> On Jan 6, 2012, at 4:42 PM, Scot Kronenfeld wrote:
>
>> I am planning to rename the tarballs and native packages that we
>> distribute.  Here is the proposed name format:
>>
>> condor-<X.Y.Z>-1.b<NMI Build ID>.<extension>
>>
>> For example:
>> condor-7.7.5-1.b24243.i686.rpm
>> condor-7.7.5-1.b24243.deb_6.0_amd64.deb
>> condor-7.7.5-b24243.tar.gz  (we will remove the 1. for tarballs.
>> It's a native package revision number that isn't useful for tarballs)
>>
>> The reason for this change is to easily distinguish between
>> pre-releases of Condor.  NMI has requested this because it is causing
>> them pain when we have them update from one pre-release to another in
>> the same Condor release.
>>
>> Any comments or questions?
>> -scot
>> _______________________________________________
>> Condor-devel mailing list
>> Condor-devel@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
>