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

[Scot Kronenfeld <kronenfe@xxxxxxxxxxx>]

On Thu, Jan 12, 2012 at 12:16 PM, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote:
>
> 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.

I agree that technically it's not that hard.  But we have to change
our process a bit to achieve this.  (E.g., one aspect of your method
that doesn't work is that we tag after we build the final release -
mainly because we are waiting to see if the tests pass.  And our tests
currently run too slowly to issue a final build the day of release
after creating the tag.)

The current process is to flip the "PRERELEASE" bit off when we think
we are ready for the final build.  Unfortunately we aren't always
right.  And it's not optimal to have multiple copies of
condor-.7.7.5-1.rpm floating around.

All that said - your feedback is noted about wanting to have a simple
name for the packages released to the general public.  The primary
goal of initiating a change right now is to have properly versioned
pre-releases so that NMI does not have upgrade problems - we'll do our
best to make sure there are no side effects of that change.

-scot