[lsb-discuss] switching numbering for data-based LSB snapshots

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Jul 2 16:00:56 UTC 2012


On Mon, Jul 2, 2012 at 9:40 AM, Robert Schweikert <rjschwei at suse.com> wrote:
> On 06/30/2012 04:03 PM, Wichmann, Mats D wrote:
>>
>> LSB development "snapshot" builds are numbered using
>> {baseversion}-{datecode}.  There's been a little irritation for a
>> long while that if you're running with these, then a released
>> version of the same {baseversion} compares less, and so won't
>> be presented as a candidate for installation.
>>
>> Recently it was requested to make a tweak to this, which
>> is documented in bug 3599.
>
>
> Why do we not just add a third digit to the release?
>
> 4.1.x


ummm, not in the bug. we have enough digits.  We have
major-minor-micro plus rpm buildno in the case of our own
code (code taken from upstream somehow has to embed
the upstream version plus ours, and we use less distinct
digits of our own in those cases)

I've struggled with an automated way to bump a digit, and
come up dry (I'll leave details to those who are curious to
ask me... a really experienced bzr developer could probably
do this but it's way too complicated for me).  So for now
that's done manually, and humans being humans, not
necessarily consistently. Sigh.

This change was simply about the difference between
builds that set OFFICIAL_RELEASE when building and ones
that don't. The ones that don't add digits representing the
date into the package name so they can quickly be seen
as snapshots, and seen by when they were built - because
it's not out of the question that a change to the SDK will
change the behavior of a package that itself has had no change
at all.

The scheme chosen for the "snapshiots" was not "clean" with respect
to rpm's EVR resolution and Russ proposed one that was clean,
that's all that was changing.  As noted this is mainly a change
for internal developers as few others use snapshots.


More information about the lsb-discuss mailing list